CA2519735C - Data transmission over a network having initially undetermined transmission capacity - Google Patents
Data transmission over a network having initially undetermined transmission capacity Download PDFInfo
- Publication number
- CA2519735C CA2519735C CA2519735A CA2519735A CA2519735C CA 2519735 C CA2519735 C CA 2519735C CA 2519735 A CA2519735 A CA 2519735A CA 2519735 A CA2519735 A CA 2519735A CA 2519735 C CA2519735 C CA 2519735C
- Authority
- CA
- Canada
- Prior art keywords
- data
- network
- rate
- video
- transmission
- 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.)
- Expired - Lifetime
Links
- 230000005540 biological transmission Effects 0.000 title claims abstract description 34
- 238000012544 monitoring process Methods 0.000 claims abstract description 8
- 230000006835 compression Effects 0.000 claims abstract description 7
- 238000007906 compression Methods 0.000 claims abstract description 7
- 230000007717 exclusion Effects 0.000 claims abstract description 3
- 238000000034 method Methods 0.000 claims description 15
- 230000005236 sound signal Effects 0.000 claims description 2
- 230000007246 mechanism Effects 0.000 abstract description 4
- 239000000872 buffer Substances 0.000 description 11
- 230000008569 process Effects 0.000 description 6
- 238000012360 testing method Methods 0.000 description 5
- 239000000463 material Substances 0.000 description 4
- 101150012579 ADSL gene Proteins 0.000 description 2
- 102100020775 Adenylosuccinate lyase Human genes 0.000 description 2
- 108700040193 Adenylosuccinate lyases Proteins 0.000 description 2
- 230000008901 benefit Effects 0.000 description 2
- 230000003139 buffering effect Effects 0.000 description 2
- 239000002131 composite material Substances 0.000 description 2
- 125000004122 cyclic group Chemical group 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 230000032258 transport Effects 0.000 description 2
- 238000010586 diagram Methods 0.000 description 1
- 238000005259 measurement Methods 0.000 description 1
- 230000010355 oscillation Effects 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/80—Responding to QoS
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/1066—Session management
- H04L65/1101—Session protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/40—Network security protocols
-
- 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/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/2662—Controlling the complexity of the video stream, e.g. by scaling the resolution or bitrate of the video stream based on the client capabilities
Abstract
Data to be transmitted over a network comprise a first part (perhaps audio) which is always to be transmitted and alternative second parts (perhaps video coded at different compression rates) of which one is to be chosen for transmission, depending on the current network capacity. In order to accommodate systems where (owing perhaps to the use of a congestion control mechanism such as TCP) the capacity available is initially undetermined, one firstly begins to transmit just the first part. When the network capacity becomes known (typically by monitoring the performance of the network in transmitting the first part), one of the alternative second parts is chosen and transmission of its commences. If desired this may initially be preferentially to, or to the exclusion of, further transmission of the first part.
Description
DATA TRANSMISSION OVER A NETWORK HAVING INITIALLY UNDETERMINED TRANSMISSION
CAPACITY
This invention is concerned with transmission of data from a sending station to a receiving terminal.
More particularly, it envisages transmission over a telecommunications network where the transmitted bit-rate that the network can support is initially undetermined. This can arise, for example, when the rate fluctuates owing to the use of a congestion control mechanism. For example, the TCP/IP system uses IP
(Internet Protocol) for transport. This is a connectionless service and simply transports transmitted packets to a destination. TCP (Transmission Control Protocol) is an overlay to this service and brings in the idea of a connection; the sending station transmits a packet and waits for an acknowledgement from the receiving terminal before transmitting another (or in the event of no acknowledgement within a timeout period, it retransmits the packet).
More importantly (in the present context) it embodies a congestion control algorithm where it begins with a small packet size and progressively increases the packet size until packet loss occurs, whereupon it reduces the size again. After this initial "slow start"
phase, the algorithm continues to increase the packet size (albeit more gradually) backing off whenever packet loss occurs; necessarily this involves some cyclic variation of the packet size. A description of TCP is to be found in "Computer Networks", by Andrew S.
Tanenbaum, third edition, 1996, pp. 521 - 542.
Another common protocol is UDP (User Data Protocol). This does not have a congestion control mechanism of its own, but it has been proposed to add one to it, the so-called "TCP-Friendly Rate Protocol (TFRC) described in the Internet Engineering Task Force (IETF) document RFC3448. This aims to establish an average transmitting data rate similar to that which the TCP algorithm would have achieved, but with a smaller cyclic variation. It too exhibits the same "slow start" phase.
One drawback of this slow start system is that the transmitting station will not "know" what bit-rate the network will provide until the slow start phase is complete ¨ which may take (depending on the round-trip time of the network) as much as several seconds.
For some applications this does not matter, but in others it does: for example, when streaming video from a server which provides a choice of compression rates, the server cannot make an informed decision at the outset about which rate to choose. In the past, one method of dealing with this has been that the server starts by transmitting the lowest quality stream and switches up to a higher rate if and when it finds that the network can support it.
CAPACITY
This invention is concerned with transmission of data from a sending station to a receiving terminal.
More particularly, it envisages transmission over a telecommunications network where the transmitted bit-rate that the network can support is initially undetermined. This can arise, for example, when the rate fluctuates owing to the use of a congestion control mechanism. For example, the TCP/IP system uses IP
(Internet Protocol) for transport. This is a connectionless service and simply transports transmitted packets to a destination. TCP (Transmission Control Protocol) is an overlay to this service and brings in the idea of a connection; the sending station transmits a packet and waits for an acknowledgement from the receiving terminal before transmitting another (or in the event of no acknowledgement within a timeout period, it retransmits the packet).
More importantly (in the present context) it embodies a congestion control algorithm where it begins with a small packet size and progressively increases the packet size until packet loss occurs, whereupon it reduces the size again. After this initial "slow start"
phase, the algorithm continues to increase the packet size (albeit more gradually) backing off whenever packet loss occurs; necessarily this involves some cyclic variation of the packet size. A description of TCP is to be found in "Computer Networks", by Andrew S.
Tanenbaum, third edition, 1996, pp. 521 - 542.
Another common protocol is UDP (User Data Protocol). This does not have a congestion control mechanism of its own, but it has been proposed to add one to it, the so-called "TCP-Friendly Rate Protocol (TFRC) described in the Internet Engineering Task Force (IETF) document RFC3448. This aims to establish an average transmitting data rate similar to that which the TCP algorithm would have achieved, but with a smaller cyclic variation. It too exhibits the same "slow start" phase.
One drawback of this slow start system is that the transmitting station will not "know" what bit-rate the network will provide until the slow start phase is complete ¨ which may take (depending on the round-trip time of the network) as much as several seconds.
For some applications this does not matter, but in others it does: for example, when streaming video from a server which provides a choice of compression rates, the server cannot make an informed decision at the outset about which rate to choose. In the past, one method of dealing with this has been that the server starts by transmitting the lowest quality stream and switches up to a higher rate if and when it finds that the network can support it.
It should be stressed that the invention does not require that either of the two protocols discussed above should be used; it does however start from the assumption that one is to transmit over a connection the bit-rate of which does not become apparent until after transmission has begun.
According to one aspect of the present invention there is provided a method of transmitting data over a network having initially undetermined transmission capacity, in which the data comprise a first part and at least two alternative second parts corresponding to respective different resolutions, for presentation at a receiving terminal simultaneously with the first part, comprising:
(a) transmitting at least an initial portion of the first part;
(b) receiving data indicative of the available transmission capacity;
(c) choosing among the alternative second parts, as a function of the data indicative of the available transmission capacity;
(d) transmitting the chosen second part and any remainder of the first part;
in which the first part is data representing an audio signal and the alternative second parts are alternative sets of video data, encoded at respective different compression rates, for presentation simultaneously with the audio data.
According to a further aspect of the present invention, the method includes the step of generating said data indicative of the available transmission capacity by monitoring the transmission by the network of the said initial portion of the first part.
According to a further aspect of the present invention, in an initial time period of step (d), transmission of a leading part of the chosen second part of an extent corresponding to the extent of the first part already transmitted is performed preferentially to, or to the exclusion of, further transmission of the first part.
Some embodiments of the invention will now be described, by way of example, with reference to the accompanying drawings, in which:
Figure 1 is a block diagram of a transmission system in accordance with one embodiment of the invention; and Figure 2 is a flowchart illustrating the operation of the server shown in Figure 1.
In this first example, a server 1 is to stream video and audio to a receiving terminal 2 via a network 3. Supposing that this material is pre-recorded, then the audio data is contained in a file A stored in a store 10, along with several versions V1, V2, V3 of the video, encoded at different compression rates.
At this point some explanations are in order, to avoid confusion. Reference will be made to the rate of audio or video material. This refers to the average rate at which bits were generated by the original encoder, which (apart from possible small differences in frequency references at the transmitting and receiving ends) is also equal to the average rate at which bits are consumed by the ultimate decoder. Even in constant bit-rate video compression, the instantaneous bit-rate varies according to picture content but is smoothed to a constant rate by the use of buffering. By "transmitting bit-rate" we mean the actual rate at which data are transmitted by the transmitting station.
For the purposes of the present example, we suppose that the audio file A has been encoded by means of some suitable compression algorithm at 4.8 kbit/s, whilst the video files V1, V2, V3 are encoded at 10, 20 and 40 kbit/s respectively, perhaps using one of the well known encoding standards such as the ITU H.261, H.283, or one of the ISO
MPEG algorithms.
The server 1 has a TCP interface 11, connected by a modem 12 to the network 3 such as the internet. The TCP interface is entirely conventional and will not be described further. It has an input 111 for data, an output 112 for sending data packets to the modem 12, and a control output 113 which indicates to the remainder of the server whether it is permitted to deliver further data to the input 111. A control unit 13 serves to read audio and video data from the store 10, and to deliver it to the input 111 of the TCP interface 11.
The data delivered to the input is also monitored by a unit 14 whose function will be described later. There is also a timer 15.
It has already been explained in the introduction that initially the server has no information about the available transmitting rate that the TCP interface 11 can deliver on to the network, and in consequence is unable to make an informed decision as to which of the three alternative video files V1, V2, V3 it should send. The rationale of the operation of this server, noting that it has only one audio file and hence no choice as to audio bit-rate, is that it delivers audio only to the interface input 111, until such time as the slow start phase of the TCP is complete (or at least, has progressed sufficiently to enable a video rate decision to be made). The purpose of the rate monitoring unit 14 is to recognise when this point has been reached. In essence, it counts the bits delivered to the interface 11, and contains (or is connected to) a timer so that it can calculate the actual transmitting bit rate that this number of bits represents. This measurement could be made over one round-trip time, but, in order to smooth out oscillations of the bit rate, one might choose to average it over a time window that is however short enough that it does not delay the recognition process significantly. Typically one might use a window length corresponding to twice (or other low multiple) of the length of the round-trip time.
Thus, the monitoring unit 13 has an output 131 which indicates the current transmitting bit-rate R.
' The system operation will now be described with reference to the flowchart shown in Figure 2. Operation begins at Step 400, where a parameter Rp representing the previous current transmitting rate is initialised to a high value, and the timer 15 is reset. At Step 401 the control unit tests the interface output 113 until it is clear to send data. Once this test is passed it reads (Step 402) audio data from the file A in the store 10 and transfers this to the interface 11. The interface 11 transmits this in accordance with normal TCP.
According to one aspect of the present invention there is provided a method of transmitting data over a network having initially undetermined transmission capacity, in which the data comprise a first part and at least two alternative second parts corresponding to respective different resolutions, for presentation at a receiving terminal simultaneously with the first part, comprising:
(a) transmitting at least an initial portion of the first part;
(b) receiving data indicative of the available transmission capacity;
(c) choosing among the alternative second parts, as a function of the data indicative of the available transmission capacity;
(d) transmitting the chosen second part and any remainder of the first part;
in which the first part is data representing an audio signal and the alternative second parts are alternative sets of video data, encoded at respective different compression rates, for presentation simultaneously with the audio data.
According to a further aspect of the present invention, the method includes the step of generating said data indicative of the available transmission capacity by monitoring the transmission by the network of the said initial portion of the first part.
According to a further aspect of the present invention, in an initial time period of step (d), transmission of a leading part of the chosen second part of an extent corresponding to the extent of the first part already transmitted is performed preferentially to, or to the exclusion of, further transmission of the first part.
Some embodiments of the invention will now be described, by way of example, with reference to the accompanying drawings, in which:
Figure 1 is a block diagram of a transmission system in accordance with one embodiment of the invention; and Figure 2 is a flowchart illustrating the operation of the server shown in Figure 1.
In this first example, a server 1 is to stream video and audio to a receiving terminal 2 via a network 3. Supposing that this material is pre-recorded, then the audio data is contained in a file A stored in a store 10, along with several versions V1, V2, V3 of the video, encoded at different compression rates.
At this point some explanations are in order, to avoid confusion. Reference will be made to the rate of audio or video material. This refers to the average rate at which bits were generated by the original encoder, which (apart from possible small differences in frequency references at the transmitting and receiving ends) is also equal to the average rate at which bits are consumed by the ultimate decoder. Even in constant bit-rate video compression, the instantaneous bit-rate varies according to picture content but is smoothed to a constant rate by the use of buffering. By "transmitting bit-rate" we mean the actual rate at which data are transmitted by the transmitting station.
For the purposes of the present example, we suppose that the audio file A has been encoded by means of some suitable compression algorithm at 4.8 kbit/s, whilst the video files V1, V2, V3 are encoded at 10, 20 and 40 kbit/s respectively, perhaps using one of the well known encoding standards such as the ITU H.261, H.283, or one of the ISO
MPEG algorithms.
The server 1 has a TCP interface 11, connected by a modem 12 to the network 3 such as the internet. The TCP interface is entirely conventional and will not be described further. It has an input 111 for data, an output 112 for sending data packets to the modem 12, and a control output 113 which indicates to the remainder of the server whether it is permitted to deliver further data to the input 111. A control unit 13 serves to read audio and video data from the store 10, and to deliver it to the input 111 of the TCP interface 11.
The data delivered to the input is also monitored by a unit 14 whose function will be described later. There is also a timer 15.
It has already been explained in the introduction that initially the server has no information about the available transmitting rate that the TCP interface 11 can deliver on to the network, and in consequence is unable to make an informed decision as to which of the three alternative video files V1, V2, V3 it should send. The rationale of the operation of this server, noting that it has only one audio file and hence no choice as to audio bit-rate, is that it delivers audio only to the interface input 111, until such time as the slow start phase of the TCP is complete (or at least, has progressed sufficiently to enable a video rate decision to be made). The purpose of the rate monitoring unit 14 is to recognise when this point has been reached. In essence, it counts the bits delivered to the interface 11, and contains (or is connected to) a timer so that it can calculate the actual transmitting bit rate that this number of bits represents. This measurement could be made over one round-trip time, but, in order to smooth out oscillations of the bit rate, one might choose to average it over a time window that is however short enough that it does not delay the recognition process significantly. Typically one might use a window length corresponding to twice (or other low multiple) of the length of the round-trip time.
Thus, the monitoring unit 13 has an output 131 which indicates the current transmitting bit-rate R.
' The system operation will now be described with reference to the flowchart shown in Figure 2. Operation begins at Step 400, where a parameter Rp representing the previous current transmitting rate is initialised to a high value, and the timer 15 is reset. At Step 401 the control unit tests the interface output 113 until it is clear to send data. Once this test is passed it reads (Step 402) audio data from the file A in the store 10 and transfers this to the interface 11. The interface 11 transmits this in accordance with normal TCP.
The control unit then interrogates the output of the monitoring unit 14 and performs some tests of the value of the current transmitting bit-rate RT and also of the timer 15 (although naturally it is not to be expected that these tests will be passed on the first iteration). Thus if (Step 403) the transmitting rate exceeds the rate needed to transmit audio plus full rate =video (i.e. 44.8 kbit/s), further monitoring of the slow start phase becomes unnecessary and the process jumps to Step 408 (described below). If not, then at Step 404 RT is tested to determine whether it exceeds its previous value.
If so it is assumed that the slow start phase is still in progress. Rp is set equal to RT
in Step 405 and the process is repeated from Step 401. If however RT Rp then the slow start phase is deemed to have ended. Rp is set equal to RT in Step 406 and the process moves on to a second phase. In the case of high round-trip times on the network, it can take a long time for the slow-start mechanism to conclude, and therefore also a test at Step 407 checks the state of the timer 15 and if this exceeds a maximum permitted waiting time the process moves on to the second phase where the video rate decision is then made on the basis of the known available transmitting bit-rate, even though this might not be the maximum.
This second phase begins with the control unit making, at Step 408, a decision as to which video rate to use. In this example, it chooses the highest rate that, with the audio, represents a total bit-rate requirement less than or equal to RT, viz.:
if RT ?_ 44.8 choose V3 if 44.8> RT 24.8 choose V2 if 24.8> RT 14.8 choose V1 if RT < 14.8 5 transmission is not possible; exit at Step 409.
Once this decision has been made, the control unit then proceeds at Step 410 to read video data from the relevant file to the TCP interface 11. It should be stressed that the initial part of this video data is contemporary (in terms of the original recorded material) with the audio already sent. Inherent in Step 410, but conventional and hence not shown explicitly, are flow control (analogous to Step 401), flow control feedback from the receiving terminal (so that the amount of data received does not cause buffer overflow) and the possibility of switching to a higher or lower rate video file in the event that network conditions improve or deteriorate, respectively.
One issue that should be considered, though, is the fact that, because, during the start-up phase, only audio has been sent, the audio buffer at the receiving terminal is ahead of the video buffer. This may be considered desirable (to a degree at least) in providing a greater resilience to short-term network problems for the audio than for the video, so that in the event of packet loss causing video buffer underflow and hence loss of video at the receiving terminal, the user may continue to listen to the accompanying sound. But, if desired, the video streaming Step 410 may temporarily, during an initial period of this second phase, slow down or even suspend transmission of audio data, until 5 the contents of the audio and video buffers at the receiving terminal reach either equality (in terms of playing time) or some other specified relationship. Naturally this has the benefit of increasing the amount of video data that can be sent during this initial period.
Possible modifications to the arrangements shown in Figure 1 include:
(a) The use of a UDP interface, with TFRC congestion control, as discussed in the introduction, in place of the TCP interface 11. In this case, because TFRC
explicitly calculates the actual transmitting rate, it may be possible to dispense with the monitoring unit 13 and instead read the transmitting rate RT directly from the UDP/TFRC
interface.
Recognition of the end of slow start may still be performed as shown in Step 404 of the flowchart by comparing RT and Rp; alternatively it may be possible to recognise it by observing when the packet loss reaches a specified level.
(b) The above description assumed that one would choose the highest video rate that the network would support; however the option also exists of deliberately choosing a lower rate in order to reduce or even eliminate the delay that occurs at the receiving terminal while the receiver video buffer is being filled to an acceptable level.
Such measures are discussed in our international patent application no. PCT/GB
01/05246 (Publication no. WO 02/45372).
(c) The above description assumed that the video and audio data originated from stored files. However this method may be applied to the transmission of a live feed, provided that the server includes additional buffering so that the video can be held at the server during the initial period of audio-only transmission.
(d) Alternative audio rates can be accommodated provide a criterion can be found whereby a decision between them can be made without recourse to any information about current network conditions. An example of this might be of an internet service that can be accessed via different access routes having vastly different bandwidths, perhaps via a standard (PSTN) telephone line and a 56 kbit/s modem on the one hand and an ADSL connection at 500 kbit/s on the other. If the system has two alternative audio rates, say 4.8 kbit/s and 16 kbit/s and one makes the reasonable assumption that the PSTN
connection can never support the higher rate and the ADSL connection always can, then if the server is informed by the receiving terminal (either automatically or manually) as to which type of access line is in use it can make a decision of which of the two audio rates to choose, based on this information alone. Once that decision has been made, the process can proceed in the manner already described.
In principle, the streaming method we have described will work with a conventional receiver. However, the benefits of the proposed method will be gained only if the receiver has the characteristic that, before beginning to play the received material, it waits until both its audio buffer and its video buffer contain sufficient data. In general, established video standards do not specify this functionality, leaving it to the discretion of the receiver designer. Of the receivers currently available, some have this characteristic whereas others, for example, may begin to decode and play audio as soon as the audio buffer is adequately full, even when no video data have arrived. We recommend that either one chooses a receiver of the former type, or one modifies the receiver control function so as to monitor the buffer contents and to initiate playing only when both buffers contain sufficient data (in accordance with the usual criteria) to support continuous playout.
A second embodiment of the invention will now be described. This is similar to the first, except that it uses layered video coding. That is to say, instead of having several (three, in the above example) different versions of the video source only one of which is sent, one has a base layer source, which can be decoded by itself to give a low-quality video output and an enhancement layer which is useless by itself but can be decoded together with the base layer to produce a higher quality video output;
and one may have further enhancement layers each of which is usable only in combination with the base layer and the intervening layer(s). In this example we also suppose that multiple (non-layered) audio rates are available. We recall that in the slow-start phase one has to transmit data in advance of deciding between the various alternative sources, and that the rationale of choosing to transmit the audio first was that since there was only one audio rate one knew that this would inevitably have to be transmitted, whatever the rate decision. In this second example with alternative audio rates this ceases to be the case, since neither audio stream qualifies as "always to be transmitted". However the video base layer does so qualify, and thus in this case one proceeds by commencing transmission of the video base layer in Step 402. Then in step 408 one selects the video and audio rates to be used and in Step 410 commences transmission of the selected audio and the enhancement layer(s), if any, appropriate to the chosen video rate. In this instance, when transmitting enhancement layer video it would be appropriate to cease transmitting base layer video until all the enhancement layer video contemporary with the base layer video already sent has been transmitted.
If so it is assumed that the slow start phase is still in progress. Rp is set equal to RT
in Step 405 and the process is repeated from Step 401. If however RT Rp then the slow start phase is deemed to have ended. Rp is set equal to RT in Step 406 and the process moves on to a second phase. In the case of high round-trip times on the network, it can take a long time for the slow-start mechanism to conclude, and therefore also a test at Step 407 checks the state of the timer 15 and if this exceeds a maximum permitted waiting time the process moves on to the second phase where the video rate decision is then made on the basis of the known available transmitting bit-rate, even though this might not be the maximum.
This second phase begins with the control unit making, at Step 408, a decision as to which video rate to use. In this example, it chooses the highest rate that, with the audio, represents a total bit-rate requirement less than or equal to RT, viz.:
if RT ?_ 44.8 choose V3 if 44.8> RT 24.8 choose V2 if 24.8> RT 14.8 choose V1 if RT < 14.8 5 transmission is not possible; exit at Step 409.
Once this decision has been made, the control unit then proceeds at Step 410 to read video data from the relevant file to the TCP interface 11. It should be stressed that the initial part of this video data is contemporary (in terms of the original recorded material) with the audio already sent. Inherent in Step 410, but conventional and hence not shown explicitly, are flow control (analogous to Step 401), flow control feedback from the receiving terminal (so that the amount of data received does not cause buffer overflow) and the possibility of switching to a higher or lower rate video file in the event that network conditions improve or deteriorate, respectively.
One issue that should be considered, though, is the fact that, because, during the start-up phase, only audio has been sent, the audio buffer at the receiving terminal is ahead of the video buffer. This may be considered desirable (to a degree at least) in providing a greater resilience to short-term network problems for the audio than for the video, so that in the event of packet loss causing video buffer underflow and hence loss of video at the receiving terminal, the user may continue to listen to the accompanying sound. But, if desired, the video streaming Step 410 may temporarily, during an initial period of this second phase, slow down or even suspend transmission of audio data, until 5 the contents of the audio and video buffers at the receiving terminal reach either equality (in terms of playing time) or some other specified relationship. Naturally this has the benefit of increasing the amount of video data that can be sent during this initial period.
Possible modifications to the arrangements shown in Figure 1 include:
(a) The use of a UDP interface, with TFRC congestion control, as discussed in the introduction, in place of the TCP interface 11. In this case, because TFRC
explicitly calculates the actual transmitting rate, it may be possible to dispense with the monitoring unit 13 and instead read the transmitting rate RT directly from the UDP/TFRC
interface.
Recognition of the end of slow start may still be performed as shown in Step 404 of the flowchart by comparing RT and Rp; alternatively it may be possible to recognise it by observing when the packet loss reaches a specified level.
(b) The above description assumed that one would choose the highest video rate that the network would support; however the option also exists of deliberately choosing a lower rate in order to reduce or even eliminate the delay that occurs at the receiving terminal while the receiver video buffer is being filled to an acceptable level.
Such measures are discussed in our international patent application no. PCT/GB
01/05246 (Publication no. WO 02/45372).
(c) The above description assumed that the video and audio data originated from stored files. However this method may be applied to the transmission of a live feed, provided that the server includes additional buffering so that the video can be held at the server during the initial period of audio-only transmission.
(d) Alternative audio rates can be accommodated provide a criterion can be found whereby a decision between them can be made without recourse to any information about current network conditions. An example of this might be of an internet service that can be accessed via different access routes having vastly different bandwidths, perhaps via a standard (PSTN) telephone line and a 56 kbit/s modem on the one hand and an ADSL connection at 500 kbit/s on the other. If the system has two alternative audio rates, say 4.8 kbit/s and 16 kbit/s and one makes the reasonable assumption that the PSTN
connection can never support the higher rate and the ADSL connection always can, then if the server is informed by the receiving terminal (either automatically or manually) as to which type of access line is in use it can make a decision of which of the two audio rates to choose, based on this information alone. Once that decision has been made, the process can proceed in the manner already described.
In principle, the streaming method we have described will work with a conventional receiver. However, the benefits of the proposed method will be gained only if the receiver has the characteristic that, before beginning to play the received material, it waits until both its audio buffer and its video buffer contain sufficient data. In general, established video standards do not specify this functionality, leaving it to the discretion of the receiver designer. Of the receivers currently available, some have this characteristic whereas others, for example, may begin to decode and play audio as soon as the audio buffer is adequately full, even when no video data have arrived. We recommend that either one chooses a receiver of the former type, or one modifies the receiver control function so as to monitor the buffer contents and to initiate playing only when both buffers contain sufficient data (in accordance with the usual criteria) to support continuous playout.
A second embodiment of the invention will now be described. This is similar to the first, except that it uses layered video coding. That is to say, instead of having several (three, in the above example) different versions of the video source only one of which is sent, one has a base layer source, which can be decoded by itself to give a low-quality video output and an enhancement layer which is useless by itself but can be decoded together with the base layer to produce a higher quality video output;
and one may have further enhancement layers each of which is usable only in combination with the base layer and the intervening layer(s). In this example we also suppose that multiple (non-layered) audio rates are available. We recall that in the slow-start phase one has to transmit data in advance of deciding between the various alternative sources, and that the rationale of choosing to transmit the audio first was that since there was only one audio rate one knew that this would inevitably have to be transmitted, whatever the rate decision. In this second example with alternative audio rates this ceases to be the case, since neither audio stream qualifies as "always to be transmitted". However the video base layer does so qualify, and thus in this case one proceeds by commencing transmission of the video base layer in Step 402. Then in step 408 one selects the video and audio rates to be used and in Step 410 commences transmission of the selected audio and the enhancement layer(s), if any, appropriate to the chosen video rate. In this instance, when transmitting enhancement layer video it would be appropriate to cease transmitting base layer video until all the enhancement layer video contemporary with the base layer video already sent has been transmitted.
Of course, if only a single audio rate were used, then both audio and base layer video could be sent during the slow-start phase.
A third embodiment, similar to the second, uses video encoded using frame rate scalability in accordance with the MPEG4 standard. An encoded MPEG sequence consists of I-frames (encoded using intra-frame coding only), P-frames (encoded using inter-frame differential coding based on the content of a preceding I-frame) and B-frames (encoded using bi-directional inter-frame prediction based on neighbouring I
and P-frames). A typical MPEG sequence might be IBBPBBPIBBP etc. In frame rate scaleable coding one transmits for the lowest bit-rate stream just the I-frames; for a higher bit-rate stream, the I and P-frames, and for a higher still bit-rate, all the frames.
In this instance one proceeds by transmitting only I-frames at Step 402 during the slow-start phase.
A yet further example is the transmission of a page for display (a "web page") consisting of text and graphics. The idea here is slightly different from the preceding examples in that we are not now concerned with the transmission of material that has to be presented to the user in real time. Nevertheless, it is considered advantageous to provide, as we provide here, for alternative graphics resolutions. So the store 10 contains text, for example in the form of an html file, and separate image files corresponding to one or more images which the receiving terminal is to display, in conventional manner, as part of a composite display. For each image there are several, perhaps three, image files stored in the store 10, at three different resolutions. The text, or the beginning of it, is transmitted in Step 402 during the slow-start phase. At Step 408 a decision is made, based on the available transmitting rate RT, as to which resolution to choose, the idea being that one chooses the highest resolution that allows the images to be transmitted in a reasonable period. The exit at 409 is not necessary in this case. Then at step 410 the remaining text (if any) is transmitted, followed by the file of the chosen resolution for the or each image. If the chosen files are renamed with filenames corresponding to those embedded in the text (i.e. independent of the resolution) then no modification at the receiving terminal is necessary and it can display the composite page using a standard web browser.
A third embodiment, similar to the second, uses video encoded using frame rate scalability in accordance with the MPEG4 standard. An encoded MPEG sequence consists of I-frames (encoded using intra-frame coding only), P-frames (encoded using inter-frame differential coding based on the content of a preceding I-frame) and B-frames (encoded using bi-directional inter-frame prediction based on neighbouring I
and P-frames). A typical MPEG sequence might be IBBPBBPIBBP etc. In frame rate scaleable coding one transmits for the lowest bit-rate stream just the I-frames; for a higher bit-rate stream, the I and P-frames, and for a higher still bit-rate, all the frames.
In this instance one proceeds by transmitting only I-frames at Step 402 during the slow-start phase.
A yet further example is the transmission of a page for display (a "web page") consisting of text and graphics. The idea here is slightly different from the preceding examples in that we are not now concerned with the transmission of material that has to be presented to the user in real time. Nevertheless, it is considered advantageous to provide, as we provide here, for alternative graphics resolutions. So the store 10 contains text, for example in the form of an html file, and separate image files corresponding to one or more images which the receiving terminal is to display, in conventional manner, as part of a composite display. For each image there are several, perhaps three, image files stored in the store 10, at three different resolutions. The text, or the beginning of it, is transmitted in Step 402 during the slow-start phase. At Step 408 a decision is made, based on the available transmitting rate RT, as to which resolution to choose, the idea being that one chooses the highest resolution that allows the images to be transmitted in a reasonable period. The exit at 409 is not necessary in this case. Then at step 410 the remaining text (if any) is transmitted, followed by the file of the chosen resolution for the or each image. If the chosen files are renamed with filenames corresponding to those embedded in the text (i.e. independent of the resolution) then no modification at the receiving terminal is necessary and it can display the composite page using a standard web browser.
Claims (3)
1. A method of transmitting data over a network having initially undetermined transmission capacity, in which the data comprise a first part and at least two alternative second parts corresponding to respective different resolutions, for presentation at a receiving terminal simultaneously with the first part, comprising:
(a) transmitting at least an initial portion of the first part;
(b) receiving data indicative of the available transmission capacity;
(c) choosing among the alternative second parts, as a function of the data indicative of the available transmission capacity;
(d) transmitting the chosen second part and any remainder of the first part;
in which the first part is data representing an audio signal and the alternative second parts are alternative sets of video data, encoded at respective different compression rates, for presentation simultaneously with the audio data.
(a) transmitting at least an initial portion of the first part;
(b) receiving data indicative of the available transmission capacity;
(c) choosing among the alternative second parts, as a function of the data indicative of the available transmission capacity;
(d) transmitting the chosen second part and any remainder of the first part;
in which the first part is data representing an audio signal and the alternative second parts are alternative sets of video data, encoded at respective different compression rates, for presentation simultaneously with the audio data.
2. A method according to claim 1 including the step of generating said data indicative of the available transmission capacity by monitoring the transmission by the network of the said initial portion of the first part.
3. A method according to claim 1 or 2 in which, in an initial time period of step (d), transmission of a leading part of the chosen second part of an extent corresponding to the extent of the first part already transmitted is performed preferentially to, or to the exclusion of, further transmission of the first part.
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
GBGB0306296.5A GB0306296D0 (en) | 2003-03-19 | 2003-03-19 | Data transmission |
GB0306296.5 | 2003-03-19 | ||
PCT/GB2004/000974 WO2004084520A1 (en) | 2003-03-19 | 2004-03-08 | Data transmission over a network having initiallly undetermined transmission capacity |
Publications (2)
Publication Number | Publication Date |
---|---|
CA2519735A1 CA2519735A1 (en) | 2004-09-30 |
CA2519735C true CA2519735C (en) | 2013-12-17 |
Family
ID=9955082
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CA2519735A Expired - Lifetime CA2519735C (en) | 2003-03-19 | 2004-03-08 | Data transmission over a network having initially undetermined transmission capacity |
Country Status (6)
Country | Link |
---|---|
US (1) | US7761901B2 (en) |
EP (1) | EP1623553B1 (en) |
AT (1) | ATE522062T1 (en) |
CA (1) | CA2519735C (en) |
GB (1) | GB0306296D0 (en) |
WO (1) | WO2004084520A1 (en) |
Families Citing this family (18)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
ES2331111T3 (en) * | 2000-11-29 | 2009-12-22 | British Telecommunications Public Limited Company | TRANSMISSION AND RECEIPT OF DATA IN REAL TIME. |
US20050021830A1 (en) * | 2001-09-21 | 2005-01-27 | Eduardo Urzaiz | Data communications method and system using buffer size to calculate transmission rate for congestion control |
US20050021821A1 (en) * | 2001-11-30 | 2005-01-27 | Turnbull Rory Stewart | Data transmission |
EP1359722A1 (en) * | 2002-03-27 | 2003-11-05 | BRITISH TELECOMMUNICATIONS public limited company | Data streaming system and method |
EP1488645B1 (en) * | 2002-03-27 | 2010-12-01 | BRITISH TELECOMMUNICATIONS public limited company | Video coding and transmission |
JP4440651B2 (en) * | 2002-03-27 | 2010-03-24 | ブリティッシュ・テレコミュニケーションズ・パブリック・リミテッド・カンパニー | Data structures for data streaming systems |
WO2006027672A2 (en) * | 2004-09-10 | 2006-03-16 | Nortel Networks | System and method for adaptive frame size management in a wireless multihop network |
EP1742476A1 (en) * | 2005-07-06 | 2007-01-10 | Thomson Licensing | Scalable video coding streaming system and transmission mechanism of the same system |
JP4986243B2 (en) * | 2008-07-04 | 2012-07-25 | Kddi株式会社 | Transmitting apparatus, method and program for controlling number of layers of media stream |
CN101534230B (en) * | 2009-04-15 | 2012-02-01 | 中控科技集团有限公司 | A method for sending data based on Ethernet, Ethernet nodes and a control system |
US9020469B2 (en) * | 2013-06-04 | 2015-04-28 | Rangecast Technologies, Llc | Network audio distribution system and method |
US10298985B2 (en) | 2015-05-11 | 2019-05-21 | Mediamelon, Inc. | Systems and methods for performing quality based streaming |
US11076187B2 (en) | 2015-05-11 | 2021-07-27 | Mediamelon, Inc. | Systems and methods for performing quality based streaming |
GB2541733B (en) | 2015-08-28 | 2019-02-13 | Imagination Tech Ltd | Bandwidth Management |
US10237319B2 (en) | 2015-10-14 | 2019-03-19 | Google Llc | Capture, recording, and streaming of media content |
US11297380B2 (en) * | 2018-12-28 | 2022-04-05 | Twitter, Inc. | Audio only content |
US10965984B1 (en) * | 2019-05-28 | 2021-03-30 | Amazon Technologies, Inc. | Minimization of video re-buffering using local animation |
JP2022041717A (en) * | 2020-09-01 | 2022-03-11 | キヤノン株式会社 | Information processing system and control method thereof |
Family Cites Families (133)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US4813044A (en) | 1987-01-30 | 1989-03-14 | International Business Machines Corporation | Method and apparatus for detecting transient errors |
USRE34824E (en) | 1987-09-23 | 1995-01-10 | British Telecommunications Public Limited Company | Video coder |
WO1990010993A1 (en) | 1989-03-16 | 1990-09-20 | Fujitsu Limited | Video/audio multiplex transmission system |
US5140417A (en) | 1989-06-20 | 1992-08-18 | Matsushita Electric Co., Ltd. | Fast packet transmission system of video data |
US5150417A (en) * | 1991-02-25 | 1992-09-22 | Socon Ab | Bass reflex type speaker system |
US5159447A (en) | 1991-05-23 | 1992-10-27 | At&T Bell Laboratories | Buffer control for variable bit-rate channel |
JP2802694B2 (en) | 1991-10-30 | 1998-09-24 | 富士写真フイルム株式会社 | Image reproducing apparatus and method |
US5506983A (en) | 1992-07-06 | 1996-04-09 | Microsoft Corporation | Method and system for transactioning of modifications to a tree structured file |
US5675696A (en) | 1992-07-14 | 1997-10-07 | Mitsubishi Denki Kabsuhiki Kaisha | Digital video signal recording and reproducing apparatus |
US5511054A (en) | 1993-03-31 | 1996-04-23 | Sony Corporation | Apparatus and method for multiplexing encoded data signals and recording medium having multiplexed signals recorded thereon |
US5561466A (en) | 1993-06-23 | 1996-10-01 | Nec Corporation | Video and audio data multiplexing into ATM cells with no dummy cell used and ATM cell demultiplexing |
AU699823B2 (en) | 1993-12-20 | 1998-12-17 | Rodney John Smith | Data compression system |
US5566208A (en) | 1994-03-17 | 1996-10-15 | Philips Electronics North America Corp. | Encoder buffer having an effective size which varies automatically with the channel bit-rate |
US5874997A (en) | 1994-08-29 | 1999-02-23 | Futuretel, Inc. | Measuring and regulating synchronization of merged video and audio data |
US5956321A (en) | 1995-03-16 | 1999-09-21 | Kabushiki Kaisha Toshiba | Stream scheduling system for real time stream server |
US5535209A (en) | 1995-04-10 | 1996-07-09 | Digital Equipment Corporation | Method and apparatus for transporting timed program data using single transport schedule |
US5822524A (en) | 1995-07-21 | 1998-10-13 | Infovalue Computing, Inc. | System for just-in-time retrieval of multimedia files over computer networks by transmitting data packets at transmission rate determined by frame size |
EP0873611A1 (en) | 1995-09-14 | 1998-10-28 | Fujitsu Network Communications, Inc. | Transmitter controlled flow control for buffer allocation in wide area atm networks |
JP3068002B2 (en) | 1995-09-18 | 2000-07-24 | 沖電気工業株式会社 | Image encoding device, image decoding device, and image transmission system |
JP3545110B2 (en) | 1995-09-26 | 2004-07-21 | 富士通株式会社 | Communication service quality control method |
JPH0993553A (en) * | 1995-09-26 | 1997-04-04 | Matsushita Electric Ind Co Ltd | Image communication equipment and image communication method |
US6122668A (en) * | 1995-11-02 | 2000-09-19 | Starlight Networks | Synchronization of audio and video signals in a live multicast in a LAN |
US5754849A (en) | 1996-01-30 | 1998-05-19 | Wayfarer Communications, Inc. | Self-describing object providing dynamic manipulation of heterogeneous data values and semantic identity between memory and transmission representations |
US5864678A (en) | 1996-05-08 | 1999-01-26 | Apple Computer, Inc. | System for detecting and reporting data flow imbalance between computers using grab rate outflow rate arrival rate and play rate |
US6396804B2 (en) | 1996-05-28 | 2002-05-28 | Qualcomm Incorporated | High data rate CDMA wireless communication system |
US6678311B2 (en) | 1996-05-28 | 2004-01-13 | Qualcomm Incorporated | High data CDMA wireless communication system using variable sized channel codes |
US5909434A (en) | 1996-05-31 | 1999-06-01 | Qualcomm Incorporated | Bright and burst mode signaling data transmission in an adjustable rate wireless communication system |
JP3668556B2 (en) | 1996-06-13 | 2005-07-06 | ソニー株式会社 | Digital signal encoding method |
KR0169248B1 (en) | 1996-07-24 | 1999-02-01 | 양승택 | Message sending apparatus and message sending controlling method in packet internetwork |
KR0178766B1 (en) | 1996-09-02 | 1999-05-15 | 삼성전자주식회사 | Apparatus for digital interface with transmission function of a non-compression digital data |
US5928330A (en) | 1996-09-06 | 1999-07-27 | Motorola, Inc. | System, device, and method for streaming a multimedia file |
US5751741A (en) | 1996-11-20 | 1998-05-12 | Motorola, Inc. | Rate-adapted communication system and method for efficient buffer utilization thereof |
US6480541B1 (en) | 1996-11-27 | 2002-11-12 | Realnetworks, Inc. | Method and apparatus for providing scalable pre-compressed digital video with reduced quantization based artifacts |
US6124878A (en) | 1996-12-20 | 2000-09-26 | Time Warner Cable, A Division Of Time Warner Enterainment Company, L.P. | Optimum bandwidth utilization in a shared cable system data channel |
US5960452A (en) | 1996-12-23 | 1999-09-28 | Symantec Corporation | Optimizing access to multiplexed data streams on a computer system with limited memory |
US6011779A (en) | 1996-12-30 | 2000-01-04 | Hyundai Electronics America | ATM switch queuing system |
US6014706A (en) | 1997-01-30 | 2000-01-11 | Microsoft Corporation | Methods and apparatus for implementing control functions in a streamed video display system |
JPH10215342A (en) * | 1997-01-31 | 1998-08-11 | Canon Inc | Image display method and device |
US6092115A (en) | 1997-02-07 | 2000-07-18 | Lucent Technologies Inc. | Method for supporting per-connection queuing for feedback-controlled traffic |
US5918020A (en) | 1997-02-28 | 1999-06-29 | International Business Machines Corporation | Data processing system and method for pacing information transfers in a communications network |
JP3003618B2 (en) | 1997-03-19 | 2000-01-31 | 日本電気株式会社 | Video transmission / reception device |
US6081843A (en) | 1997-03-20 | 2000-06-27 | Nokia Telecommunications | System using simulation cell and simulation buffer for regulating cell transfer rate according to occupancy level of the simulation buffer |
US6240103B1 (en) | 1997-03-21 | 2001-05-29 | Scientific-Atlanta, Inc. | Method and apparatus for detecting and preventing bandwidth overflow in a statistical multiplexer |
KR100302263B1 (en) | 1997-03-25 | 2001-09-22 | 모리시타 요이찌 | Stream data transmission method and system |
US6269078B1 (en) | 1997-04-04 | 2001-07-31 | T. V. Lakshman | Method and apparatus for supporting compressed video with explicit rate congestion control |
US6181821B1 (en) | 1997-04-30 | 2001-01-30 | Massachusetts Institute Of Technology | Predictive source encoding and multiplexing |
DE69810250T2 (en) | 1997-05-26 | 2003-10-09 | Koninkl Philips Electronics Nv | SYSTEM FOR PLAYING BACK DATA IN A DATA FLOW SERVER |
US6310857B1 (en) | 1997-06-16 | 2001-10-30 | At&T Corp. | Method and apparatus for smoothing and multiplexing video data flows |
US6014694A (en) * | 1997-06-26 | 2000-01-11 | Citrix Systems, Inc. | System for adaptive video/audio transport over a network |
US6573907B1 (en) * | 1997-07-03 | 2003-06-03 | Obvious Technology | Network distribution and management of interactive video and multi-media containers |
JP3547944B2 (en) | 1997-07-17 | 2004-07-28 | Kddi株式会社 | Dubbing data transmission device for digital VTR |
US6065104A (en) | 1997-07-23 | 2000-05-16 | S3 Incorporated | Method of embedding page address translation entries within a sequentially accessed digital audio data stream |
US6701372B2 (en) | 1997-08-22 | 2004-03-02 | Canon Kabushiki Kaisha | Data communication apparatus and method |
US6324165B1 (en) | 1997-09-05 | 2001-11-27 | Nec Usa, Inc. | Large capacity, multiclass core ATM switch architecture |
JP3478100B2 (en) | 1997-12-09 | 2003-12-10 | 三菱電機株式会社 | Radio channel allocation apparatus and radio channel allocation method |
US6285661B1 (en) | 1998-01-28 | 2001-09-04 | Picturetel Corporation | Low delay real time digital video mixing for multipoint video conferencing |
US6216173B1 (en) | 1998-02-03 | 2001-04-10 | Redbox Technologies Limited | Method and apparatus for content processing and routing |
EP0939545A2 (en) | 1998-02-27 | 1999-09-01 | Hitachi, Ltd. | Video service system |
US6373855B1 (en) * | 1998-03-05 | 2002-04-16 | Intel Corporation | System and method for using audio performance to control video bandwidth |
JPH11261589A (en) | 1998-03-13 | 1999-09-24 | Fujitsu Ltd | Atm network system |
US6895048B2 (en) | 1998-03-20 | 2005-05-17 | International Business Machines Corporation | Adaptive encoding of a sequence of still frames or partially still frames within motion video |
IL123906A0 (en) | 1998-03-31 | 1998-10-30 | Optibase Ltd | Method for synchronizing audio and video streams |
JP4366725B2 (en) | 1998-04-01 | 2009-11-18 | ソニー株式会社 | Image signal processing apparatus and method, and image signal recording apparatus and method |
US6104441A (en) | 1998-04-29 | 2000-08-15 | Hewlett Packard Company | System for editing compressed image sequences |
JPH11341477A (en) | 1998-05-25 | 1999-12-10 | Niles Parts Co Ltd | Image storage processing unit |
EP1414246B1 (en) | 1998-06-18 | 2007-02-28 | Sony Corporation | Electronic program guide multiplexed in an MPEG stream |
US6584509B2 (en) | 1998-06-23 | 2003-06-24 | Intel Corporation | Recognizing audio and video streams over PPP links in the absence of an announcement protocol |
US6850564B1 (en) | 1998-06-26 | 2005-02-01 | Sarnoff Corporation | Apparatus and method for dynamically controlling the frame rate of video streams |
US6097697A (en) | 1998-07-17 | 2000-08-01 | Sitara Networks, Inc. | Congestion control |
US6622171B2 (en) * | 1998-09-15 | 2003-09-16 | Microsoft Corporation | Multimedia timeline modification in networked client/server systems |
GB9821792D0 (en) | 1998-10-06 | 1998-12-02 | Sgs Thomson Microelectronics | Data transfer |
US6618363B1 (en) | 1998-10-09 | 2003-09-09 | Microsoft Corporation | Method for adapting video packet generation and transmission rates to available resources in a communications network |
US6445701B1 (en) | 1998-10-09 | 2002-09-03 | Microsoft Corporation | Channel access scheme for use in network communications |
FR2784844B1 (en) | 1998-10-14 | 2002-03-29 | France Telecom | METHOD FOR SWITCHING OVER THE VIDEO COMPONENT (S) OF A FIRST DIGITAL AUDIOVISUAL PROGRAM ONTO THE COMPONENT (S) OF A SECOND DIGITAL AUDIOVISUAL PROGRAM |
KR100310055B1 (en) | 1998-10-28 | 2001-12-17 | 구자홍 | Device and method for changing recording speed of optical disc recorder / player |
JP2000151705A (en) | 1998-11-16 | 2000-05-30 | Dainippon Printing Co Ltd | Information distribution system and server therefor |
US6637031B1 (en) | 1998-12-04 | 2003-10-21 | Microsoft Corporation | Multimedia presentation latency minimization |
EP1021044A1 (en) | 1999-01-12 | 2000-07-19 | Deutsche Thomson-Brandt Gmbh | Method and apparatus for encoding or decoding audio or video frame data |
EP1033846A1 (en) | 1999-03-01 | 2000-09-06 | Alcatel | Process for controlling uplink packet transmission in a wireless communication network |
WO2000055854A1 (en) | 1999-03-17 | 2000-09-21 | Kabushiki Kaisha Toshiba | Method for recording stream data and its data structure |
US6625119B1 (en) | 1999-03-17 | 2003-09-23 | 3Com Corporation | Method and system for facilitating increased call traffic by switching to a low bandwidth encoder in a public emergency mode |
US6470378B1 (en) * | 1999-03-31 | 2002-10-22 | Intel Corporation | Dynamic content customization in a clientserver environment |
US7086077B2 (en) | 1999-04-01 | 2006-08-01 | Sedna Patent Services, Llc | Service rate change method and apparatus |
US6754189B1 (en) | 1999-04-08 | 2004-06-22 | Lucent Technologies Inc. | Method of queue length based burst management in wireless communication systems |
EP1045555A3 (en) | 1999-04-09 | 2003-04-23 | Sun Microsystems, Inc. | Method and apparatus for management of communications over media of finite bandwidth |
US6614843B1 (en) | 1999-04-15 | 2003-09-02 | Diva Systems Corporation | Stream indexing for delivery of interactive program guide |
US6501797B1 (en) * | 1999-07-06 | 2002-12-31 | Koninklijke Phillips Electronics N.V. | System and method for improved fine granular scalable video using base layer coding information |
IT246858Y1 (en) | 1999-07-16 | 2002-04-10 | Italtinto Srl | DISPENSING-DOSING MACHINE FOR PAINT OR SIMILAR DYES WITH CENTRAL SIMULTANEOUS DISPENSING GROUP OF DYES AND CLEANING SYSTEM |
US6697369B1 (en) | 1999-09-28 | 2004-02-24 | Lucent Technologies Inc | Admission control adjustment in data networks using maximum cell count |
US7522631B1 (en) | 1999-10-26 | 2009-04-21 | Qualcomm, Incorporated | Method and apparatus for efficient data transmission control in a wireless voice-over-data communication system |
US7206580B2 (en) | 1999-11-04 | 2007-04-17 | Qualcomm Incorporated | Method and apparatus for performing handoff in a high speed communication system |
US7203732B2 (en) | 1999-11-11 | 2007-04-10 | Miralink Corporation | Flexible remote data mirroring |
JP2001144802A (en) | 1999-11-11 | 2001-05-25 | Canon Inc | Apparatus, method and system for data communication and storag medium |
US6700893B1 (en) | 1999-11-15 | 2004-03-02 | Koninklijke Philips Electronics N.V. | System and method for controlling the delay budget of a decoder buffer in a streaming data receiver |
GB9928023D0 (en) | 1999-11-26 | 2000-01-26 | British Telecomm | Video transmission |
CA2291835A1 (en) | 1999-12-06 | 2001-06-06 | Nortel Networks Corporation | Load adaptive buffer management in packet networks |
US6593930B1 (en) | 1999-12-16 | 2003-07-15 | Intel Corporation | Method and apparatus to execute a memory maintenance operation during a screen blanking interval |
KR100677083B1 (en) | 2000-01-27 | 2007-02-01 | 삼성전자주식회사 | Transmission/receipt data processing method for inhibiting error propagation in digital image data communication system and computer-readable medium therefor |
EP1130921B1 (en) | 2000-03-02 | 2005-01-12 | Matsushita Electric Industrial Co., Ltd. | Data transmission in non-reliable networks |
US7106906B2 (en) | 2000-03-06 | 2006-09-12 | Canon Kabushiki Kaisha | Moving image generation apparatus, moving image playback apparatus, their control method, and storage medium |
US7058723B2 (en) | 2000-03-14 | 2006-06-06 | Adaptec, Inc. | Congestion control for internet protocol storage |
US6493388B1 (en) | 2000-04-19 | 2002-12-10 | General Instrument Corporation | Rate control and buffer protection for variable bit rate video programs over a constant rate channel |
US6813275B1 (en) | 2000-04-21 | 2004-11-02 | Hewlett-Packard Development Company, L.P. | Method and apparatus for preventing underflow and overflow across an asynchronous channel |
US6738386B1 (en) | 2000-05-11 | 2004-05-18 | Agere Systems Inc. | Controlled latency with dynamically limited queue depth based on history and latency estimation |
GB2362532B (en) | 2000-05-15 | 2004-05-05 | Nokia Mobile Phones Ltd | Video coding |
US7260826B2 (en) | 2000-05-31 | 2007-08-21 | Microsoft Corporation | Resource allocation in multi-stream IP network for optimized quality of service |
GB2366464A (en) | 2000-08-14 | 2002-03-06 | Nokia Mobile Phones Ltd | Video coding using intra and inter coding on the same data |
US6909693B1 (en) | 2000-08-21 | 2005-06-21 | Nortel Networks Limited | Performance evaluation and traffic engineering in IP networks |
GB2367219A (en) * | 2000-09-20 | 2002-03-27 | Vintage Global | Streaming of media file data over a dynamically variable bandwidth channel |
US6993604B2 (en) | 2000-11-15 | 2006-01-31 | Seagate Technology Llc | Dynamic buffer size allocation for multiplexed streaming |
ES2331111T3 (en) | 2000-11-29 | 2009-12-22 | British Telecommunications Public Limited Company | TRANSMISSION AND RECEIPT OF DATA IN REAL TIME. |
US7277955B2 (en) | 2000-12-22 | 2007-10-02 | Verizon Corporate Services Group Inc. | Streaming content |
US20020122491A1 (en) | 2001-01-03 | 2002-09-05 | Marta Karczewicz | Video decoder architecture and method for using same |
US6920175B2 (en) | 2001-01-03 | 2005-07-19 | Nokia Corporation | Video coding architecture and methods for using same |
US20020131496A1 (en) * | 2001-01-18 | 2002-09-19 | Vinod Vasudevan | System and method for adjusting bit rate and cost of delivery of digital data |
US20030012287A1 (en) | 2001-03-05 | 2003-01-16 | Ioannis Katsavounidis | Systems and methods for decoding of systematic forward error correction (FEC) codes of selected data in a video bitstream |
EP1241891A1 (en) | 2001-03-13 | 2002-09-18 | eJay AG | Apparatus and method for transmitting audio and/or video data |
EP1384153A4 (en) * | 2001-05-04 | 2005-08-03 | Netqos Inc | Server-site response time computation for arbitrary applications |
TW511365B (en) | 2001-05-15 | 2002-11-21 | Corbett Wall | Method allowing individual user to record song and forward to others for listening by connecting to a service provider with telecommunication device signal |
AU2002314309A1 (en) * | 2001-06-11 | 2002-12-23 | C-Burn Systems Ltd | Selecting tracks from a jukebox via a wireless communications device |
US7191246B2 (en) | 2001-07-18 | 2007-03-13 | Sharp Laboratories Of America, Inc. | Transmission rate selection for a network of receivers having heterogenous reception bandwidth |
US7106758B2 (en) | 2001-08-03 | 2006-09-12 | Adc Telecommunications, Inc. | Circuit and method for service clock recovery |
US7142509B1 (en) | 2001-09-12 | 2006-11-28 | Extreme Networks | Method and apparatus providing for delivery of streaming media |
US20050021830A1 (en) | 2001-09-21 | 2005-01-27 | Eduardo Urzaiz | Data communications method and system using buffer size to calculate transmission rate for congestion control |
US20030076858A1 (en) * | 2001-10-19 | 2003-04-24 | Sharp Laboratories Of America, Inc. | Multi-layer data transmission system |
US6898313B2 (en) * | 2002-03-06 | 2005-05-24 | Sharp Laboratories Of America, Inc. | Scalable layered coding in a multi-layer, compound-image data transmission system |
EP1488645B1 (en) | 2002-03-27 | 2010-12-01 | BRITISH TELECOMMUNICATIONS public limited company | Video coding and transmission |
JP4440651B2 (en) | 2002-03-27 | 2010-03-24 | ブリティッシュ・テレコミュニケーションズ・パブリック・リミテッド・カンパニー | Data structures for data streaming systems |
EP1359722A1 (en) | 2002-03-27 | 2003-11-05 | BRITISH TELECOMMUNICATIONS public limited company | Data streaming system and method |
US7039712B2 (en) * | 2002-10-16 | 2006-05-02 | Microsoft Corporation | Network connection setup procedure for traffic admission control and implicit network bandwidth reservation |
US20050010697A1 (en) * | 2002-12-30 | 2005-01-13 | Husam Kinawi | System for bandwidth detection and content switching |
US20040181817A1 (en) * | 2003-03-12 | 2004-09-16 | Larner Joel B. | Media control system and method |
KR20060088303A (en) | 2005-02-01 | 2006-08-04 | 엘지전자 주식회사 | Apparatus and method recording/playing moving picture in digital broadcasting receiver |
-
2003
- 2003-03-19 GB GBGB0306296.5A patent/GB0306296D0/en not_active Ceased
-
2004
- 2004-03-08 CA CA2519735A patent/CA2519735C/en not_active Expired - Lifetime
- 2004-03-08 AT AT04718334T patent/ATE522062T1/en not_active IP Right Cessation
- 2004-03-08 WO PCT/GB2004/000974 patent/WO2004084520A1/en active Application Filing
- 2004-03-08 EP EP04718334A patent/EP1623553B1/en not_active Expired - Lifetime
- 2004-03-08 US US10/549,582 patent/US7761901B2/en active Active
Also Published As
Publication number | Publication date |
---|---|
US20060182016A1 (en) | 2006-08-17 |
CA2519735A1 (en) | 2004-09-30 |
WO2004084520A1 (en) | 2004-09-30 |
ATE522062T1 (en) | 2011-09-15 |
EP1623553A1 (en) | 2006-02-08 |
GB0306296D0 (en) | 2003-04-23 |
EP1623553B1 (en) | 2011-08-24 |
US7761901B2 (en) | 2010-07-20 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CA2519735C (en) | Data transmission over a network having initially undetermined transmission capacity | |
JP4426316B2 (en) | Data streaming system and method | |
US8621061B2 (en) | Adaptive bitrate management for streaming media over packet networks | |
EP2159684B1 (en) | Playback of streamed media | |
US7644176B2 (en) | Devices and methods for minimizing start up delay in transmission of streaming media | |
US7974200B2 (en) | Transmitting and receiving real-time data | |
JP4440651B2 (en) | Data structures for data streaming systems | |
WO2004008673A2 (en) | Method for enabling packet transfer delay compensation in multimedia streaming | |
KR20060011964A (en) | Method and device for proactive rate adaptation signaling | |
AU2002231829A1 (en) | Method and system for buffering streamed data | |
JP5207895B2 (en) | Transmitting apparatus, receiving apparatus, method, and program | |
JP4903435B2 (en) | Media signal transmission method and reception method, and transmission / reception method and apparatus | |
Nguyen et al. | Streaming and congestion control using scalable video coding based on H. 264/AVC | |
Chattopadhyay et al. | Adaptive rate control for H. 264 based video conferencing over a low bandwidth wired and wireless channel | |
KR20050019880A (en) | Method for enabling packet transfer delay compensation in multimedia streaming | |
Chou et al. | MPEG-4 video streaming with drift-compensated bitstream switching |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
EEER | Examination request |