EP1943601A1 - Method and apparatus for traffic flow control of streaming video data - Google Patents

Abstract

A method and apparatus are provided for transmitting streaming video. The method and apparatus include dynamically altering the transmission rate based on bandwidth considerations; or predicting bandwidth availability in a network, or both.

Description

METHOD AND APPARATUS FOR TRAFFIC FLOW CONTROL OF STREAMING VIDEO

DESCRIPTION

The present application is related to and claims priority from U.S. Patent Application Serial Number 60/730,088 (Atty. Docket 001362) entitled "Interactive Patient Care System" and filed on October 25, 2005. The disclosure of that application is specifically incorporated herein by reference.

Video communications are ubiquitous in present society. In addition to many traditional displays such as television, devices such as computers, personal digital assistants (PDAs) and cellular telephones are adapted to receive video information for display.

Video is often delivered over a network via an internet protocol (IP) . One type of video that is often provided over an IP is streaming video. Streaming video is often transmitted over a network. For example, the streaming video may be transmitted over a broadband network. Typically, streaming media is transferred in packets over the network. A short amount of the video, perhaps one second, is buffered locally in a streaming video player to average out fluctuations in the channel. The streaming video player plays the video from the buffer which is often a block of local memory (RAM) .

Streaming video can require relatively large bandwidth capabilities for efficient transmission. If the medium between the transmitter and the receiver of the streaming video cannot provide the requisite bandwidth, degradation of the quality of the images may result. This degradation can be manifest as artifacts and macroblocking, for example. As the disparity between the bandwidth requirements and the bandwidth availability increases, the severity of the video degradation increases. Illustratively, the duration and severity of artifacts can increase.

One approach to ensuring a particular quality of service (QoS) of streaming video is to provide a dedicated endpoint- to-endpoint link for the streaming video. Such a link will ensure a specified bandwidth is maintained. While a dedicated link is useful in providing a guaranteed QoS of streaming video, the use of such a link is reserved for one, or at most a few users. Because each link must be established and equipment is required for each link, the cost and efficiency of such an undertaking is impractical. There is a need for a method and apparatus for providing streaming video that overcomes at least the shortcomings noted above .

In accordance with an example embodiment, a method of video communication includes transmitting streaming video over a non-dedicated communication link. The method further includes receiving the streaming video and determining a bandwidth change in the link. Furthermore, the method includes altering the rate of the transmitting based on the change .

In accordance with another example embodiment, an apparatus for video transmission and reception includes a media server adapted to transmit streaming video and a video player adapted to receive the streaming video. Based on a bandwidth change in a link between the video player and the media server, the video player is adapted to alter a transmission rate of the streaming video. In accordance with yet another example embodiment, in a communication system, a method of video communication includes: transmitting streaming video in packets from a media server to a video player at a first transmission rate; determining a number of packets lost in the transmitting; comparing the number of packets lost to a threshold value; and based on the comparing, continuing the transmitting at the first transmission rate or switching the transmitting to a second transmission rate. In accordance with yet another embodiment, in a communication system, a method of video communication, includes estimating a bandwidth capacity for one or more paths of the video communication. The method also includes based on the estimating, selecting a transmission rate for each of the paths; and transmitting streaming video from a media server to a video player along each path at the selected transmission rate.

The invention is best understood from the following detailed description when read with the accompanying drawing figures. It is emphasized that the various features are not necessarily drawn to scale. In fact, the dimensions may be arbitrarily increased or decreased for clarity of discussion.

Fig. 1 is a simplified block diagram of a patient information system in accordance with an example embodiment. Fig. 2 is a flow-diagram of a method in accordance with an example embodiment.

Fig. 3 is a flow-diagram of a method in accordance with an example embodiment. Fig. 4 is a flow-diagram of a method in accordance with an example embodiment. In the following detailed description, for purposes of explanation and not limitation, example embodiments disclosing specific details are set forth in order to provide a thorough understanding of the present teachings. However, it will be apparent to one having ordinary skill in the art having had the benefit of the present disclosure that other embodiments that depart from the specific details disclosed herein. Moreover, descriptions of well-known devices, hardware, software, methods, systems and protocols may be omitted so as to not obscure the description of the example embodiments. Nonetheless, such hardware, software, devices, methods, systems and protocols that are within the purview of one of ordinary skill in the art may be used in accordance with the example embodiments. Finally, wherever practical, like reference numerals refer to like features.

The example embodiments described relate to a patient information system in which streaming video may be provided to a patient. The patient information system may be as described in the above-referenced application. However, the present teachings are not limited to patient information system applications. To this end, other applications of the present teachings are contemplated and such applications may be effected in embodiments unrelated to patient information systems. For example, the methods and apparati of the present teachings may be implemented in entertainment applications, non-medical educational video services, and video gaming. Beneficially, the methods and apparati of the present teachings result in the communication of streaming video that at most minimally interferes with the QoS of other users of a network.

Fig. 1 is a simplified block diagram of a patient information system 100 in accordance with an example embodiment. The system 100 includes a patient system 101, a server 102 and a clinician terminal 103. The server 102 and the patient system 101 are in communication via a network 104. The link between the network and the patient terminal is illustratively in accordance with a known internet protocol (IP) . The network 104 may be a broadband network over coaxial cable or over a fiber-optic link. In either case, known components and software may be implemented to realize the networks. For example, in a fiber-optic network equipment such as transceivers would be provided and in the broadband cable network, equipment such as cable-modems would be provided.

Alternatively, the network 104 may be a wireless network or a digital subscriber line (XDSL) network. The wireless network would include the infrastructure specified by the protocol of the system. For example, the wireless network could be in compliance with the IEEE 802.11, or its progeny, or compliance with proposed IEEE 802.22, often referred to as spectrum agile radio systems (SARS) . The XDSL network would be implemented over plain old telephone service (POTS) lines with the requisite XDSL infrastructure.

The clinician terminal 103 may be a personal computer having the requisite presentation layer software (user interface software) for interfacing with the server 102, the network 104 and the patient system 101. The terminal 103 may be connected to a server 102 through a known intranet connection, such as a wired or wireless connection. The server 102, which may be referred to as a host center, and the intranet connection are well-known to one skilled in the art of information technology and as such are not described in detail to avoid obscuring the description of the embodiments .

In the example embodiment presently described, in the interest of simplicity of description, one patient system 101, one server 102 and one clinician terminal 103 are shown and described. However, it is contemplated that the patient information system 100 includes a plurality of the patient systems 101, a plurality of servers 102 and a plurality of clinician terminals 103 as needed.

The server 102 includes a processor 105. The server 102 also includes a measurement server 106, a device database 112 and a media delivery server 108. In an example embodiment, the server 102 may be an integrated component of hardware, software and firmware. Communications between the network 104 and the processor 105 and the network 104 and the measurement server 106 are illustratively in accordance with the hypertext transfer protocol (HTTP) . Many features of the servers 106-108 are common to and described in detail in the above-referenced application. Certain salient features are provided herein.

The measurement server 106 receives the measurement data from the patient system 101 via the network. These data are analyzed at the measurement server for appropriate action by the clinician. The data garnered from the measurement server 106 are provided via an SQL link to the database 112. In addition, the measurement server 106 provides the measurement analysis (e.g., reports or digests) to the clinician terminal 103 via the intranet. The media delivery server 108 provides the streaming video as well as information in other formats to the patient information system 101. The streaming video may be in accordance with the real time streaming protocol (RTSP) , or the real time protocol (RTP) or the real time control protocol (RTCP) .

The processor 105 includes a configuration server 109, a set-top box (STB) server 110 and a STB loader server 111. The details of these components are found in the incorporated application referenced above.

Due to the sensitivity of the information being transferred between the clinician and the patient, the links between the terminal 103, the server 102 and the patient system 101 are beneficially secure. In a specific embodiment, the connection includes encryption and other known security measures to provide a virtual private network (VPN) in accordance with the virtual private network consortium (VPNC) . In this manner, the secure link may be provided via public access links, such as telephone and coaxial cable lines. Alternatively, if a wireless local area network wireless (LAN) or wireless wide are network (WAN) are used in any of the links of the example embodiments, known encryption and security measures may be implemented to ensure that information transmitted over the link is secure.

The patient system 101 includes a control module 113 that may be an STB as described in the above-referenced application. Notably, the control module 113 may be referred to as a video player. In a specific embodiment, the control module 113 converts and displays streaming video from the media delivery server 108. The control module also includes firmware 114, an STB loader 115, a TV user-interface (UI) 116 and a measurement gateway 117. The firmware 114 and the STB loader are adapted to decode streaming video from the media delivery server 108. The hardware, software and firmware required for this decoding is specific to the protocol used for transmission of the streaming video. A plurality of measurement devices 118 may be included, but not in all systems. The measurement devices may be coupled to the client module 113 by a wired or wireless link. The control module also is coupled to a video display 119 and may be controlled by a remote control device 120. Details of the components and functions of the patient system 101 are described more fully in the above-referenced application.

Fig. 2 is a flow-diagram of a method of streaming video traffic control in accordance with an example embodiment. The method is best understood when reviewed in conjunction with Fig. 1 as well. Common details are generally not repeated so as to avoid obscuring the description of the present example embodiments. At step 201, the patient system 101 receives streaming video. In a specific embodiment, the streaming video is digitized video packet data transmitted in accordance with the RTSP protocol from the media delivery server 108. The decoding of these data is known to one skilled in the art. At step 202, the patient system 101 determines that a change in the transmission bandwidth of the streaming video link has occurred. The determination of the change in the transmission bandwidth may be accomplished by a number of methods. Illustratively, the firmware 114 and loader 115 of the STB 113 include a decoder. The decoder is adapted to determine the number and severity of artifacts present in a streaming video signal from the media delivery server 108. If there are artifacts, the media delivery server 108 and the network 104 are presently unable to meet the bandwidth of the decoder. Thus, the media delivery server 108 and the network 104 are unable to provide digitized streaming video at a rate required by the control module 113 (video player) to generate uninterrupted video images, and the decoder detects this failure. Alternatively, the bandwidth capability of the media delivery server 113 and the network 104 may be increased. In this case, the control module 113 detects the under-use of capacity. At step 203, the media delivery server 108 alters the transmission rate. The altering of the transmission rate of the streaming video may be effected to achieve different goals. In one example embodiment, the STB 113 provides a message to the media delivery server 108 that the transmission rate of the streaming video is too great for the present capacity of the network. With this error message, the STB 113 may include a command to transmit at a lower data rate . In a specific embodiment, the media delivery server 108 is adapted to provide multiple streams of video simultaneously and substantially synchronized. Each stream is provided at a different transmission rate; but only one of the streams may be transmitted to the STB 113 at a time. If the current stream is too great for present network capacity, the command from the STB 113 will include an instruction to switch to a specified lower transmission rate. Moreover, the different video streams may include indices or markers identifying particular frames of the streaming video. The command would identify a next marker at which to switch to the streaming video of a lower transmission rate. At the switch, the media delivery server 108 will transmit the selected streaming video to the network 104 for delivery to the STB 113. As noted previously, the STB 113 is adapted to detect transmission errors. In a specific embodiment, a header is provided in the stream of video packets. The header will include the duration and transmission rate of the streaming video. If the packets of streaming video are not arriving at the prescribed data rate, or if certain packets do not arrive at the STB 113, or both, the STB 113 will algorithmically determine the rate of transmission, or quantify the number of packets lost in a particular period of time, or both. After this determination, the STB 113 algorithmically determines a lower rate of transmission.

An error message is then sent to the media delivery server 108 with instructions on an action to be taken. Illustratively, the action may include instructing the server 104 to transmit another of the simultaneous video streams at a defined index point. Alternatively, the action may instruct the server 104 to terminate transmission if the bandwidth capability is insufficient to maintain transmission of the streaming video.

At the termination of step 203, the process may be repeated beginning at step 201.

Among other benefits, the methods of the example embodiments foster providing a suitable streaming video QoS to the patient. Notably, if the service is lowered, it is acceptable; and if insufficient bandwidth does not exist presently, the video may be viewed at a later time when the network 103 and server 108 can maintain at least a minimum transmission rate. Moreover, the termination of service will reduce the loading of the network 104 and server 108. As such other users in the network 104 will have improved service. For example, terminating one video stream for a time may suffice to allow the transmission of other video streams at full or reduced transmission rates. Fig. 3 is a flow-diagram of a method of streaming video traffic control in accordance with an example embodiment. The method is best understood when reviewed in conjunction with Fig. 1 as well. Common details are generally not repeated so as to avoid obscuring the description of the present example embodiments.

At step 301, the media delivery server 108 extracts a measure of the packet loss rate of streaming video packets transmitted from the media delivery server 108 to the patient system 101. The method of determining packet loss may be a known method. Illustratively, known techniques of compiling packet-loss statistics from the receiver (e.g., the STB 113) may be implemented via the chosen protocol. For example, RTP or RTSP protocols provide for determining packet loss statistics at the receiver of the packets. According to an example embodiment, these data may be provided to the media delivery server 108.

At step 302, the packet loss data is compared to a threshold value. In an example embodiment, the media delivery server 108 is adapted to algorithmically compare the packet loss data with the threshold value. Notably, there may be more than one threshold value, with each value corresponding to a particular transmission rate. Based on the comparison, the algorithm would determine if any change in the transmission rate is required to maintain a particular QoS; and if a change is required to select the transmission rate most closely related to one of the threshold values. For purposes of illustration, suppose there are three threshold values of packet loss rate, Tl, T2 and T3, where Tl represents the greatest threshold (lowest transmission rate) and T3 represents the lowest threshold (highest transmission rate) . Suppose that the packet loss data were between Tl and T2. Because selecting the highest transmission rate (corresponding to the highest transmission rate) would result in an unacceptable QoS, the server would select the transmission rate corresponding to the second threshold T2. In this manner, the QoS would be acceptable. If the server 108 were already transmitting at this ^Λmid' data rate, no change would be required. If the server 108 were transmitting at a higher data rate, the server 108 would change the transmission rate to the middle transmission rate. Finally, if the server 108 were transmitting at a lower data rate, the server 108 would change its transmission rate to a higher data rate.

In an example embodiment, the determination of packet loss of other error correction technique may be carried out based on a number of criteria. For example, sampled transmissions to determined packet loss may be carried out at predetermined time intervals or at specified times; or may be based on data based, such as at selected data points. In addition, the sampling rate may be governed by the most recent error data. To this end, if the packet loss data from a most recent sample is near a threshold, the sampling rate may be increased as the likelihood of reaching the threshold level may also be increased.

At step 303, if the packets lost value is at or above the threshold, the method continues to step 304. At step 304, the server will switch to another transmission rate based on the analysis of step 302. If at step 303, the packets lost value is below the threshold, the method continues to step 305. The server will continue to transmit the streaming video at the same rate. At the end of steps 304, 305 the method repeats beginning at step 301.

Fig. 4 is a flow diagram of a method of streaming video communication in accordance with an example embodiment. Unlike the methods described to this point, which were dynamic in nature, the present method is more predictive. The method is best understood when reviewed in conjunction with Fig. 1 as well. Common details are generally not repeated so as to avoid obscuring the description of the present example embodiments. Notably, combined methods and apparati for transmitting streaming video incorporating aspects of both the dynamic and the predictive methods of the example embodiments are contemplated. At step 401, the bandwidth capacity of one or more of the paths between the media delivery server 108 and the STB 113 are estimated. In one embodiment, a static gross map of potential congestion of data traffic in the paths is determined. In another embodiment, the potential congestion may be computed based on expected data traffic loading for each path. The static map or the function are illustratively based on locations of receivers (e.g., STBs 113) and network information such as IP addresses and pathchar function call results.

At step 402, based on the estimate, the transmission rate (bitrate) for a video stream or a group of video streams may be determined. Notably, the estimate will provide capacity levels for data transmission for each path. Illustratively, the server 108 selects a transmission rate commensurate with the loading capacity of the paths.

At step 403, the streaming video is transmitted at the selected transmission rate. In an embodiment, a sequence of streams are transmitted at selected transmission rates based on the predicted traffic loading of the paths between the server 108 and the STB 113 at the time of transmission of each video stream.

In view of this disclosure it is noted that the various methods and devices described herein can be implemented in hardware and software. Further, the various methods and parameters are included by way of example only and not in any limiting sense. In view of this disclosure, those skilled in the art can implement the present teachings in determining their own techniques and needed equipment to effect these techniques, while remaining within the scope of the appended claims .

Claims

1. A method of video communication, comprising: transmitting streaming video over a communication link; receiving the streaming video (201); determining a bandwidth change in the link (202); and altering a rate of decoding the streaming video based on the bandwidth change (203) .

2. A method as recited in claim 1, wherein the altering further comprises reducing the rate (304) of the transmitting if the bandwidth change is negative.

3. A method as recited in claim 1, wherein the altering further comprises terminating the transmitting (304) if the bandwidth change results in a bandwidth that is less than a minimum value.

4. A method as recited in claim 1, wherein the altering further comprises: simultaneously providing more than one video stream of the streaming video and each of the video streams is provided at a different transmission rate; and based on the bandwidth change, switching to another of the video streams that is transmitted at a lower transmission rate .

5. A method as recited in claim 1, wherein the altering further comprises: simultaneously providing more than one video stream of the streaming video and each of the video streams is provided at a different transmission rate; and based on the bandwidth change, switching to another of the video streams that is transmitted at a higher transmission rate.

6. A method as recited in claim 4, further comprising: including indices at selected points of each of the video streams; and effecting the switching at a next index of the another video stream.

7. An apparatus for video transmission and reception, comprising: a video player (113), which receives streaming video and, based on a bandwidth change, alters a transmission rate of the streaming video.

8. An apparatus as recited in claim 7, wherein the video player reduces the transmission rate if the bandwidth change is negative.

9. An apparatus as recited in claim 7, wherein the video player terminates transmission of the streaming video.

10. An apparatus as recited in claim 7, wherein a media server (108) simultaneously provides more than one video stream of the streaming video and each of the video streams is provided at a different transmission rate and the video player is adapted to select one of video streams based on the bandwidth change.

11. An apparatus as recited in claim 7, wherein the video player is a component of a patient information system (100) and the media server is a component of a host center (102) .

12. In a communication system, a method of video communication, comprising: transmitting streaming video in packets from a media server to a video player at a first transmission rate; determining a number of packets lost (301) in the transmitting; comparing the number of packets lost (302) to a threshold value; and based on the comparing, continuing the transmitting at the first transmission rate (305) or switching the transmitting to a second transmission rate (304).

13. A method as recited in claim 12, wherein the second transmission rate is less than the first transmission rate.

14. A method as recited in claim 12, wherein the wherein the second transmission rate is greater than the first transmission rate.

15. A method as recited in claim 12, wherein the video player is a component of a patient information system (100) and the media server is a component of a host center.

16. In a communication system, a method of video communication, comprising: estimating a bandwidth capacity for one or more paths of the streaming video communication (401); based on the estimating, selecting a transmission rate for each of the paths (402); and transmitting streaming video from a media server to a video player along each path at the selected transmission rate (403) .

17. A method as recited in claim 16, wherein the estimating further comprises: compiling a static gross map of the paths of the system; and predicting locations on the map where traffic congestion may occur.

18. A method as recited in claim 16, wherein the estimating further comprises: computing a function of expected traffic loading for each of the paths of the system.