Sender-based adaptive bitrate control

Abstract

Techniques are described for streaming (e.g., low-latency streaming) media content by performing sender-based adaptive bitrate control operations. The operations can include streaming a media stream to a streaming client. While streaming the media stream, an outgoing queue of buffered streaming content to be sent to the streaming client can be monitored. Based at least in part on the monitoring, when a downgrade condition is satisfied, a lower bitrate media stream can be switched to for streaming to the streaming client. Based at least in part on the monitoring, when an upgrade condition is satisfied, a higher bitrate media stream can be switched to for streaming to the streaming client. The operations are performed without receiving any quality feedback from the streaming client and without measuring a bandwidth of a network channel.

Description

BACKGROUND

[0001] Media streaming solutions for media content use lossless network protocols for media delivery over a network. Common media streaming solutions include HTTP Live Streaming (HLS) and HTTP Dynamic Adaptive Streaming (DASH). Such media streaming solutions typically deliver media content as files. The reliance on lossless protocols and the use of files for delivering media content results in high or very high latency depending on the underlying conditions (e.g., network conditions). For example, if the network experiences a burst loss of a few seconds, the streaming client will lag behind the live media stream by a corresponding amount. In addition, head-of-line blocking and TCP congestion control algorithms increase the latency of the network when problems (e.g., congestion or network packet loss) are encountered.

[0002] With typical adaptive bitrate streaming techniques, a streaming client decides which bitrate stream to request based on current conditions at the client (e.g., network conditions). For example, if the client determines that the network throughput is greater than the current bitrate stream it is receiving, the client can send feedback to the server to request a higher bitrate stream. However, such typical solutions suffer from increased latency and can be inefficient when streaming to a large number of streaming clients. SUMMARY

[0003] This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the detailed description. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used in limiting the scope of the claimed subject matter.

[0004] Techniques are described for low latency streaming of media content. For example, sender-based adaptive bitrate control operations can be performed for each of a plurality of streaming clients, including streaming a media stream including encoded video data to a streaming client at a first bitrate. The operations can also include monitoring an outgoing queue of buffered streaming content to be sent to the streaming client. The operations can also include, based at least in part on the monitoring, switching to a media stream at a lower bitrate for streaming to the streaming client when a downgrade condition is satisfied. The operations can also include, based at least in part on the monitoring, switching to a media stream at a higher bitrate for streaming to the streaming client when an upgrade condition is satisfied. The sender-based adaptive bitrate control operations are performed for the plurality of streaming clients without receiving any quality feedback from the plurality of streaming clients and without measuring bandwidth of a network channel for streaming to the plurality of streaming clients.

[0005] As another example, sender-based adaptive bitrate control operations are performed for each of a plurality of streaming clients. The operations include, while in a monitoring state: streaming a media stream comprising encoded video data to a streaming client at a first bitrate; monitoring an outgoing queue of buffered streaming content to be sent to the streaming client; based at least in part on the monitoring, when a downgrade condition is satisfied, transitioning to a downgraded state to switch to a lower bitrate media stream for streaming to the streaming client; and based at least in part on the monitoring, when an upgrade condition is satisfied, transitioning to an upgraded state to switch to a higher bitrate media stream for streaming to the streaming client. The operations also include, while in the downgraded state: remaining in the downgraded state for a downgrade freeze interval, during which no bitrate changes are made, and upon expiration of the downgrade freeze interval, transitioning to the monitoring state. The operations further include, while in the upgraded state: when a resume upgrade condition is satisfied, transitioning to a resume upgraded state to resume the first bitrate based at least in part on the monitoring of the outgoing queue of buffered streaming content, and when the resume upgrade condition is not satisfied, and upon expiration of an upgrade freeze interval during which no bitrate changes are made, transitioning to the monitoring state. The sender-based adaptive bitrate control operations are performed for the plurality of streaming clients without receiving any quality feedback from the plurality of streaming clients and without measuring bandwidth of a network channel for streaming to the plurality of streaming clients. BRIEF DESCRIPTION OF DRAWINGS

[0006] Figure 1 is a block diagram depicting an example environment for low-latency streaming of media content, including performing sender-based adaptive bitrate control.

[0007] Figure 2 is an example state diagram for performing sender-based adaptive bitrate control operations.

[0008] Figure 3 is a flow diagram of an example method for low-latency streaming of media content, including performing sender-based adaptive bitrate control operations.

[0009] Figure 4 is a flow diagram of an example method for low-latency streaming of media content, including performing sender-based adaptive bitrate control operations to transition between states.

[0010] Figure 5 is a diagram of an example computing system in which some described embodiments can be implemented.

[0011] Figure 6 is an example cloud support environment that can be used in connection with the techniques described herein. DETAILED DESCRIPTION

[0012] SUMMARY

[0013] The following description relates to techniques for low-latency streaming of media content (e.g., using a lossless protocol). For example, sender-based adaptive bitrate control operations can be performed for each of a plurality of streaming clients. The operations can include streaming a media stream including encoded video data to the streaming clients at a first bitrate. While streaming the media stream, an outgoing queue of buffered streaming content to be sent to the streaming clients can be monitored. Based at least in part on the monitoring, when a downgrade condition is satisfied, a media stream at a lower bitrate can be switched to for streaming to the streaming clients. Based at least in part on the monitoring, when an upgrade condition is satisfied, a media stream at a higher bitrate can be switched to for streaming to the streaming clients. The sender-based adaptive bitrate control operations are performed for the plurality of streaming clients without receiving any quality feedback from the plurality of streaming clients and without measuring bandwidth of a network channel for streaming to the plurality of streaming clients.

[0014] In typical streaming solutions, the streaming protocol relies on the client to calculate the available bandwidth based on the speed of downloading file segments. Based on this information, the client detects the available bandwidth and requests a quality change (i.e., a bitrate change) from the sender (e.g., a server or service sending the media stream to the client). This approach takes a significant amount of time because the client needs to calculate the bandwidth, detect the change, and send the request to the sender. As a result, the longer the underlying network is overused or congested, the greater the impact on latency and user experience.

[0015] Furthermore, with typical streaming solutions, it can be difficult or impossible to measure network bandwidth by observing the data stream because the data is sent to the network at the rate it is produced. Thus, the rate at which it is received does not necessarily indicate the available bandwidth. If the data is sent at a higher rate, the network can or can not support the higher rate.

[0016] The techniques described herein provide various advantages for streaming of media content (e.g., for low-latency streaming of media content). Generally, these techniques provide sender-based solutions (also referred to as sender-side solutions) that efficiently detect when congestion occurs in a network channel and react by reducing the bit rate (e.g., by switching to a lower bit rate stream). Conversely, when no network congestion is detected in the network channel, these techniques periodically test whether the bit rate can be increased (e.g., by switching to a higher bit rate stream). The techniques described herein detect when congestion or potential congestion occurs by monitoring the outgoing queue of buffered streaming content (e.g., by monitoring only the outgoing queue of buffered streaming content).

[0017] Sender-based solutions provide this automatic bit rate control without receiving any quality feedback from the streaming client and without measuring the bandwidth of the network channel for streaming to the streaming client. As a result of these sender-based solutions, streaming is provided in a more efficient manner and with reduced latency.

[0018] These solutions provide reduced-latency streaming because the sender (e.g., a streaming service) does not need to wait for feedback from the streaming client when automatically adjusting the bit rate. For example, the sender can detect congestion in the network channel based only on the outgoing queue at the sender (e.g., by measuring its fullness) and quickly reduce to a lower bit rate without having to wait for the streaming client to detect the problem and communicate with the sender.

[0019] These solutions improve the efficiency of streaming because the sender (e.g., a streaming service) can make bit rate decisions for many streaming clients based only on the outgoing queue and without receiving any quality feedback from the streaming clients. For example, network and computing resources are saved because the sender does not receive or process quality feedback from the streaming clients.

[0020] These solutions allow the sender (e.g., a streaming service) to automatically select the highest bit rate stream that fits the available bandwidth. For example, the sender reduces the bit rate when the outgoing queue indicates congestion and attempts to increase the bit rate (e.g., periodically) when the outgoing queue indicates no congestion. In this way, the sender can automatically transition between states of monitoring the outgoing queue and performing upgrade and downgrade operations based at least in part on the fullness of the outgoing queue.

[0021] These solutions allow the sender (e.g., a streaming service) to minimize playback stalls. By quickly and efficiently detecting congestion and switching (e.g., immediately switching) to a lower bitrate stream, playback stalls are minimized. Similarly, when attempting to increase the bitrate, congestion can be quickly detected, and the bitrate increase can be reverted (e.g., by immediately switching back).

[0022] These solutions also allow for manual control of the bitrate. For example, a client can decide to move to a manual control mode, where the client selects the bitrate, and the sender uses the selected bitrate without performing any adaptive rate control. If needed, the client can later switch back to the sender-side adaptive rate control solution.

[0023] The techniques described herein can be used to efficiently (e.g., with low overhead) stream audio and / or video content to streaming clients with low latency. The techniques described herein can be used with file-based streaming protocols, such as HLS, and ultra-low latency protocols, as long as the protocol uses an outgoing queue for each streaming client.

[0024] The techniques described herein can also be applied to semi-lossless protocols (also referred to as semi-lossy and / or lossy) by using loss rate reports from the client or packet retransmission requests (NACKs) or similar feedback from the client that provides the sender with insights into the underlying conditions between the sender and the client.

[0025] The techniques described herein for streaming media content using sender-based adaptive bitrate control can be integrated with other techniques for low latency streaming of media content, such as the techniques described in U.S. Patent Application No. 17 / 670,148, titled “ULTRA-LOW LATENCY VIDEO STREAMING,” filed February 11, 2022.

[0026] Terminology

[0027] The term “media content” refers to encoded audio and / or video content. The encoded audio and / or video content contains a sequence of encoded audio and / or video frames (e.g., including corresponding audio and / or video samples). The encoded audio and / or video frames are encoded via corresponding audio and / or video codecs.

[0028] The term “streaming” refers to transmitting media content as a media stream from a first computing device to a second computing device via a computer network. For example, a media stream can be streamed from a streaming service to one or more streaming clients via one or more respective network channels.

[0029] The term "lossless protocol" refers to one or more network protocols that provide reliable data transmission over a computer network from a first computing device (e.g., a server) to a second computing device (e.g., a client). When data fails to reach its destination computing device, a lossless protocol retransmits the data until it is successfully received (thus providing reliable transmission). Examples of lossless protocols include Transmission Control Protocol (TCP), Hypertext Transfer Protocol (HTTP), HTTP Live Streaming (HLS), and HTTP Dynamic Adaptive Streaming (DASH). In some implementations, lossless transport protocols such as TCP are used to ensure reliable data transmission to the client. However, in other implementations, lossy protocols, such as User Datagram Protocol (UDP), can be used, with higher-level protocols providing reliable delivery over the entire network channel between the sender and client.

[0030] The term "semi-lossless protocol" refers to one or more network protocols that provide semi-reliable data transmission over a computer network from a first computing device (e.g., a server) to a second computing device (e.g., a client). Semi-lossless protocols can provide different levels of reliability (e.g., different delivery modes).

[0031] The term "streaming client" refers to a client that receives streaming audio and / or video data. For example, a streaming client can be a software application running on a computing device (e.g., a laptop or desktop computer, tablet computer, smartphone, or other type of computing device) that decodes and renders (e.g., via audio and / or video playback) the received media stream.

[0032] The term "sender" refers to a software and / or hardware solution that sends (transmits) streaming audio and / or video data to one or more streaming clients. A sender can be a server or streaming service that sends streaming audio and / or video data to one or more streaming clients (e.g., streaming to multiple streaming clients). A sender can also be another type of computing device and / or software solution (e.g., a desktop computer, laptop computer, smartphone, or another type of computing device running software that streams audio and / or video data to one or more streaming clients).

[0033] The term "sender-based" adaptive bitrate control refers to operations performed by the sender of the media stream (e.g., a server or service that sends the media stream to a client). Sender-based operations differ from those performed by the streaming client, which is the receiver of the media stream.

[0034] Example media streams and outgoing queues

[0035] In the techniques described herein, media content is delivered to clients as media streams (e.g., as live media streams or as another type of media stream). For example, the media content of a media stream can be for live delivery to a client. Due to the various network conditions between the sender and the client, an outgoing queue is maintained for each streaming client.

[0036] Each client (also referred to as a streaming client) has an associated outgoing queue of streaming content to be sent to the cache of the streaming client. For a given streaming client, the outgoing queue of cached streaming content contains streaming content that is ready to be delivered to the given streaming client or has already been sent to the given streaming client but has not yet been acknowledged as received by the given streaming client. In some implementations, the outgoing queue of cached streaming content stores buffers that are scheduled to be sent to the streaming client but have not yet been indicated as sent. In some implementations, the outgoing queue of cached streaming content is monitored (e.g., to determine how full or how much of the available buffers they occupy) using an application programming interface (API) call or system call. The specific call depends on the operating system and / or application being used. For example, when using the Windows® operating system, the Windows® Input / Output Completion Port (IOCP) API can be used, and when using the Linux® operating system, the Linux® io_uring system call can be used.

[0037] The fullness of the outgoing queue of cached streaming content refers to how much of the outgoing queue is available to add streaming content relative to how much of the queue currently stores cached streaming content to be sent to the streaming client. The fullness metric can indicate a specific percentage of the outgoing queue that is currently occupied (e.g., in terms of the total space of the queue, available buffers, or some other metric). For example, if a given outgoing queue has 100 buffers, and 40 of the buffers contain cached streaming content (and the remaining 60 are empty), the given outgoing queue would be 40% full.

[0038] Environment for sender-based adaptive bitrate control

[0039] Figure 1 ​​is a diagram depicting an example environment 100 for low-latency streaming of media content (e.g., using a lossless protocol), including performing sender-based adaptive bitrate control. The example environment 100 includes a streaming service 110. The streaming service 110 provides media content for streaming to streaming clients, including streaming clients 130, 132, and 134. In some implementations, the streaming service 110 streams media content to the streaming clients, including streaming client 130, streaming client 132, and streaming client 134, using a lossless protocol. The streaming service 110 can be implemented using various types of software and / or hardware computing resources, such as server computers, cloud computing resources, audio and / or video encoding software, streaming software, etc. While the streaming service 110 is one example of a solution for performing the sender-based adaptive bitrate control techniques described herein, other types of senders (e.g., other software and / or hardware solutions) can perform the operations described with respect to the streaming service 110.

[0040] The streaming service 110 performs various operations for streaming media streams to the streaming clients, as shown at 112. For example, the operations can include sender-based adaptive bitrate control operations in which the bitrate is automatically adjusted by the streaming service 110 without requiring any quality feedback from the streaming clients (e.g., from streaming clients 130, 132, and 134) and without measuring the bandwidth of the network channel used to stream the media content to the streaming clients.

[0041] In this example, the streaming service 110 provides media streams to three streaming clients (streaming client 130, streaming client 132, and streaming client 134), as shown at 140. The streaming service 110 maintains an outgoing queue of buffered streaming content for each streaming client. Specifically, streaming client 130 is associated with queue 120, streaming client 132 is associated with queue 122, and streaming client 134 is associated with queue 124. Each queue indicates encoded audio and / or video data that is waiting to be delivered to its respective streaming client. For ease of illustration, the example environment 100 depicts three streaming clients and their respective queues. However, the example environment 100 supports any number of streaming clients and associated queues.

[0042] As depicted, each of the queues stores an amount of streaming content to be delivered to a streaming client. For example, queue 120 currently contains an amount of streaming content represented by the dashed portion waiting to be delivered to streaming client 130. As shown by the dashed portion, queue 120 is not very full (e.g., 30% full). On the other hand, queue 122 is almost full (e.g., 80% full).

[0043] Streaming service 110 can perform adaptive bitrate control operations by monitoring the queues (e.g., by monitoring queues 120, 122, and 124). For example, streaming service 110 can monitor how full each queue is and lower or increase the bitrate accordingly. In some implementations, streaming service 110 performs a degrading operation to lower the bitrate when a degrading condition is met and a upgrading operation to increase the bitrate when an upgrading condition is met.

[0044] Streaming service 110 operates without using per-client quality feedback from the streaming clients (e.g., from streaming clients 130, 132, and 134). For example, when streaming service 110 performs adaptive bitrate control operations, streaming service 110 does so without using quality feedback from the streaming clients (e.g., the streaming clients do not send any information to the streaming service indicating that the streaming clients are experiencing network loss, delay, or congestion). In some implementations, streaming service 110 uses only information about the queues when determining whether to adjust the bitrate.

[0045] Sender-based adaptive bitrate control using state transitions

[0046] Figure 2 is an example state diagram 200 for performing sender-based adaptive bitrate control operations (e.g., using a lossless protocol). For example, a streaming service (e.g., streaming service 110) can perform sender-based adaptive bitrate control for each of a plurality of streaming clients by transitioning between the states depicted in example state diagram 200.

[0047] Example state diagram 200 is used when monitoring an outgoing queue of buffered streaming content for sending to a streaming client. In some implementations, the monitoring is performed before each frame or packet is sent to the outgoing queue, and the state transitions can occur at this frequency. Other implementations can monitor the queue on another periodic basis (e.g., based on a number of frames, an amount of streaming content, or an amount of time).

[0048] The example state diagram 200 includes a monitoring state 212. The monitoring state 212 is the starting state and the state to which the monitoring returns when the sender-based adaptive bitrate control is disabled and re-enabled. From the monitoring state 212, based on monitoring of the outgoing queue of buffered streaming content for a given client, the bitrate of the given streaming client can be increased (e.g., by switching to a higher bitrate stream) or decreased (e.g., by switching to a lower bitrate stream).

[0049] While in the monitoring state 212, the streaming service monitors the condition of the queue of buffered streaming content. When a downgrade condition is satisfied during monitoring of a given queue and the bitrate is not at the lowest bitrate, the streaming service switches to a lower bitrate media stream to stream to the streaming client associated with the given queue by transitioning to the downgrade state 210. As depicted at 220, the downgrade condition is determined at least in part by checking whether the network connection between the streaming service and the streaming client is unstable, and if the downgrade condition is determined, the transition to the downgrade state 210 is performed. In some implementations, the downgrade condition is satisfied when the fullness of the outgoing queue of buffered streaming content is above a threshold (e.g., when the queue is more than 50% full or more than 50% occupied of the available buffers in the queue), which indicates unstable network conditions (e.g., network channel congestion or likely to become congested).

[0050] In some implementations, determining whether the downgrade condition is satisfied for a given streaming client is based only on monitoring of the outgoing queue of streaming content for the given streaming client (e.g., performed by the monitoring state 212). In this way, the streaming service can efficiently perform adaptive bitrate control without needing to receive any quality feedback from the streaming client and without needing to measure the bandwidth of the network channel. This also allows the streaming service to efficiently scale to many streaming clients while maintaining ultra-low latency.

[0051] While in the downgrade state 210, the streaming service waits for a period of time for the network congestion to resolve and for the network to become stable. This period of time is referred to as the “downgrade freeze interval.” During this period of time while in the downgrade state 210, no bitrate switching is performed (i.e., even if network instability is detected, the streaming service does not increase or decrease the bitrate during this period of time). As depicted at 222, after the downgrade freeze interval has expired, the streaming service transitions back to the monitoring state 212, where switching of the bitrate can now occur.

[0052] When in the monitoring state 212, the streaming service monitors the condition of the outgoing queue of buffered streaming content. When the upgrade condition is met during monitoring of a given queue and the bit rate is not at the highest bit rate, the streaming service switches to a higher bit rate of media stream to stream to the streaming client associated with the given queue by transitioning to the upgrade state 214. In some implementations, the upgrade condition is met when at least two criteria are met. The first is that the fullness of the outgoing queue of buffered streaming content is below a threshold (indicating network stability). The second is that a probe interval has been reached. The probe interval is designed such that the monitoring service attempts to periodically increase the bit rate.

[0053] In some implementations, determining whether the upgrade condition is met for a given streaming client is based only on monitoring (e.g., performed by the monitoring state 212) of the outgoing queue of streaming content for the given streaming client. In this way, the streaming service can efficiently perform adaptive bit rate control without receiving any quality feedback from the streaming client and without measuring the bandwidth of the network channel. This also allows the streaming service to efficiently scale to many streaming clients while maintaining ultra-low latency.

[0054] While in the monitoring state 212, when the upgrade condition has been met, the streaming service attempts to increase the bit rate, as depicted at 224, and transitions to the upgrade state 214. The upgrade state 214 is a transitional state that the streaming service enters when probing to determine whether the network will support a higher bit rate. While in the upgrade state 214, the condition of the outgoing queue of buffered streaming content is monitored, and there are two possible transitions. The first is that if network instability is detected (e.g., if the fullness of the queue is above a threshold), the streaming service transitions (e.g., immediately transitions) to the resume upgrade state 216, as depicted at 225. This process allows the streaming service to probe the condition of the streaming client’s network connection and attempt a higher bit rate stream, but if instability is detected after (e.g., immediately after) the switch, the resume upgrade state 216 can be used to resume the bit rate. If the resume upgrade state 216 is entered, the monitoring service waits for a period of time for network congestion to resolve and for the network to become stable. This period of time is referred to as a “degrade freeze interval after probe.” While in the resume upgrade state 216 during this period of time, no bit rate switching is performed (i.e., the streaming service does not increase or decrease the bit rate during this period of time, even if network instability is detected). After the degrade freeze interval after probe has expired, the streaming service transitions back to the monitoring state 212, as depicted at 228, where switching of the bit rate can now occur.

[0055] A second possible transition from the upgrade state 214 will occur if the network is stable (i.e., no network instability is detected by monitoring the queue) for a period of time referred to as the "upgrade freeze interval." During this time, no transitions will be made. However, after this period of time (if the network remains stable for the upgrade freeze interval), the monitoring service will transition back to the monitoring state 212, as shown at 226, where switching of the bit rate can now occur.

[0056] In some implementations, the downgrade freeze interval after probing is selected to be longer (e.g., substantially longer) than the downgrade freeze interval. The reason the downgrade freeze interval can be shorter is that the reason for transitioning to the downgrade state 210 is a change in network conditions, which can have changed significantly and require further downgrading to be performed. In contrast, the transition to the resume upgrade state 216 is caused by a failed upgrade operation (a failed transition to a higher bit rate), so the network conditions can not be worse than they were before, and further downgrading is less likely. Thus, more time can be provided to resolve congestion before returning to the monitoring state 212.

[0057] In the techniques described herein, determining whether the network (referring to the network connection or network channel between the streaming service and the streaming client) is stable (or unstable) is performed by monitoring the state of the outgoing queue of the cached streaming content. If the fullness of the queue is above a threshold, then the network is considered unstable (i.e., network instability has been detected). Otherwise, the network is considered stable. In some implementations, the threshold changes depending on previous monitoring results. For example, when the previous monitoring results indicate a stable network, then a first threshold is used. Otherwise, when the previous monitoring results indicate an unstable network, then a second threshold (different from the first threshold) is used. In some implementations, the second threshold is lower than the first threshold. As an example, the first threshold can be 50% and the second threshold can be 20% (e.g., indicating that 80% of the queue is empty). In this way, a more stringent threshold can be implemented for stability when the network was previously unstable.

[0058] The techniques described herein periodically probe the network to check whether the bit rate can be increased. This technique is used because the bandwidth of the network channel is not measured or cannot be measured. The periodic probing technique can also provide a more accurate indication of whether the network can support a higher bit rate than what a direct measurement of the bandwidth can indicate.

[0059] In some implementations, the probing interval is increased as failed upgrade operations occur. Increasing the probing interval in this way reduces the likelihood that the streaming client will experience video stalling. For example, if the streaming service attempts to increase the bit rate, but fails (e.g., by detecting network instability and transitioning to the resume upgrade state 216), the streaming service increases the probing interval (e.g., exponentially) so that the streaming service waits a longer period of time before probing the network again to determine whether it will support a higher bit rate. In some implementations, the probing interval is controlled by the following equation:

[0060] Probing Interval = check interval * 2 min(failed checks failed checks ceiling)

[0061] (Equation 1)

[0062] The "check interval" is a multiplier for the probing interval and can be a predetermined or user-configurable setting. As an example, the check interval can be 30 seconds. The "failed checks" count starts at zero and is incremented each time a failed upgrade operation occurs. The "failed checks ceiling" value places an upper limit on the probing interval. To illustrate the probing interval calculation, if the check interval is 30 seconds, the failed checks count is 3 (indicating three previous failed upgrade operations), and the failed checks ceiling is 8, then the probing interval will be 240 seconds. In some implementations, the probing interval is reset (by resetting the failed checks count to zero) when the media stream has been playing successfully and there have been no failed upgrade operations for a period of time referred to as the failed checks reset interval.

[0063] In some implementations, the adaptive bit rate control of the streaming service is disabled. For example, the streaming client can send a message to the streaming service to disable monitoring and automatic bit rate selection. This option is indicated by the manual override 230 transition. When disabled, the streaming service enters the disabled state 218 in which automatic bit rate selection is disabled. In this state, the streaming service can use a manually selected bit rate (e.g., selected by the streaming client). If a decision is made to return to adaptive bit rate selection, the monitoring service transitions back to the monitoring state 212 as indicated at 232.

[0064] In some implementations, when switching to a different bit rate, the switch does not occur immediately. Rather, the switch occurs on the next key video frame (e.g., an I-frame, an IDR frame, or another type of key or independent video frame). In some embodiments, when switching to a different bit rate, the streaming is paused until the next key video frame. This can be useful when congestion is detected and the streaming service is degrading, and not sending any video frames (or any streaming content) until the next key video frame can help to alleviate the congestion.

[0065] Table 1 below lists various parameters described herein. These parameters are associated with example default values. However, different default values can be used depending on the implementation.

[0066]

[0067] Table 1 - Example Parameters

[0068] In some implementations, sender-based adaptive bit rate control operations are performed for multiple streaming clients (e.g., by a streaming service such as streaming service 110) based only on sender-side monitoring of outgoing queues of buffered streaming content. For example, the streaming service uses a state diagram such as example state diagram 200 to perform adaptive bit rate control and manage transitions between states (including a monitoring state, a degradation state, an upgrade state, a recovery upgrade state, a disable state, and / or other states that can be used to perform adaptive bit rate control). In this way, the streaming service can efficiently perform adaptive bit rate control without needing to receive any quality feedback from the streaming clients and without needing to measure bandwidth of the network channel. This also allows the streaming service to efficiently scale to many streaming clients while maintaining ultra-low latency.

[0069] Method for sender-based adaptive bit rate control

[0070] In any of the examples herein, a method for low-latency streaming of media content (e.g., using a lossless protocol) can be provided by performing sender-based adaptive bit rate control operations. Sender-based adaptive bit rate control can be performed by monitoring outgoing queues of buffered streaming content, and performing bit rate control operations (e.g., increasing or decreasing the bit rate) based on the results of the monitoring.

[0071] Figure 3 is a flowchart of an example method 300 for low-latency streaming of media content (e.g., using a lossless protocol). For example, the example method 300 can be performed by a streaming service such as streaming service 110.

[0072] At 310, a sender-based adaptive bitrate control operation is performed for each of the one or more streaming clients. In some implementations, the sender-based adaptive bitrate control operation includes operations 320-350. Moreover, the sender-based adaptive bitrate control operation is performed for a streaming client without receiving any quality feedback from the streaming client and without measuring bandwidth of a network channel for streaming to the streaming client.

[0073] At 320, a media stream is streamed to the streaming client at a first bitrate. The media stream includes encoded video content. The media stream is streamed to the streaming client via a network channel (e.g., a network channel between a streaming service and the streaming client).

[0074] At 330, an outgoing queue of buffered streaming content to be sent to the streaming client is monitored. The monitoring can include assessing a fullness of the queue (e.g., based on a percentage of the queue that is full or empty, based on a percentage of allocated buffers that are utilized or not utilized, and / or based on other criteria that indicate how full or empty the queue is).

[0075] At 340, a switch to a lower bitrate media stream is performed for streaming to the streaming client when a downgrade condition associated with the outgoing queue of buffered streaming content is satisfied. The lower bitrate media stream has a lower bitrate relative to the first bitrate (e.g., the first bitrate can be 2000 kbps and the lower bitrate can be 1200 kbps). At least in part, the downgrade condition is satisfied when a fullness of the outgoing queue of buffered streaming content is above a threshold. Other criteria can also be required to satisfy the downgrade condition, such as the current bitrate not being the lowest possible bitrate.

[0076] At 350, a switch to a higher bitrate media stream is performed for streaming to the streaming client when an upgrade condition associated with the outgoing queue of buffered streaming content is satisfied. The higher bitrate media stream has a higher bitrate relative to the first bitrate. At least in part, the upgrade condition is satisfied when a fullness of the outgoing queue of buffered streaming content is below a threshold and when a probe interval is reached. Other criteria can also be required to satisfy the upgrade condition, such as the current bitrate not being the highest possible bitrate.

[0077] Figure 4 is a flow diagram of an example method 400 for low latency streaming of media content (e.g., using a lossless protocol), including performing sender-based adaptive bitrate control operations to transition between states. For example, the example method 400 can be performed by a streaming service, such as the streaming service 110.

[0078] At 410, sender-based adaptive bitrate control operations are performed for each of the one or more streaming clients by transitioning between states (e.g., operations 411-434). Moreover, the sender-based adaptive bitrate control operations are performed for the streaming clients without receiving any quality feedback from the streaming clients and without measuring bandwidth of the network channel for streaming to the streaming clients.

[0079] At 411, sender-based adaptive bitrate control operations are performed while in the monitoring state. In some implementations, the operations include operations 412-418. At 412, the media stream is streamed to the streaming client at a first bitrate (e.g., via a lossless protocol). At 414, the outgoing queue of buffered streaming content to be sent to the streaming client is monitored. At 416, based at least in part on the monitoring, a transition to a degraded state is performed when a degradation condition associated with the outgoing queue of buffered streaming content is satisfied. The transition to the degraded state causes a switch to a lower bitrate media stream for streaming to the streaming client. The lower bitrate media stream has a lower bitrate relative to the first bitrate. At 418, based at least in part on the monitoring, a transition to an upgraded state is performed when an upgrade condition associated with the outgoing queue of buffered streaming content is satisfied. The transition to the upgraded state causes a switch to a higher bitrate media stream for streaming to the streaming client. The higher bitrate media stream has a higher bitrate relative to the first bitrate.

[0080] At 420, sender-based adaptive bitrate control operations are performed while in the degraded state. At 422, the streaming service remains in the degraded state for a degraded freeze interval. During this interval, no bitrate changes are made. At 424, upon expiration of the degraded freeze interval, a transition back to the monitoring state at 411 is performed, where bitrate changes can now be performed based on the monitoring results.

[0081] At 430, sender-based adaptive bitrate control operations are performed while in the upgraded state. While in the upgraded state, the queue is monitored for instability. At 432, based at least in part on the monitoring, a transition to a recovered upgraded state is performed when a recovered upgrade condition associated with the outgoing queue of buffered streaming content is satisfied, which recovers (e.g., immediately recovers) to a previous bitrate (e.g., to the first bitrate). In some implementations, the recovered upgrade condition is satisfied when the monitoring of the outgoing queue of buffered streaming content indicates that the fullness is above a threshold (e.g., as performed at 414). Otherwise (when the recovered upgrade condition is not satisfied), at 434, upon expiration of an upgraded freeze interval, a transition back to the monitoring state at 411 is performed.

[0082] Additional Embodiments

[0083] Example 1 is a computing device comprising a processor, a network interface, and a memory, the computing device configured to perform operations for low-latency streaming of media content. The operations comprise performing, for each of a plurality of streaming clients, sender-based adaptive bitrate control operations including streaming, to a streaming client, a media stream comprising encoded video data at a first bitrate, monitoring an outgoing queue of buffered streaming content to be sent to the streaming client, based at least in part on the monitoring, when a downgrade condition associated with the outgoing queue of buffered streaming content is satisfied, switching to a media stream at a lower bitrate relative to the first bitrate for streaming to the streaming client, and based at least in part on the monitoring, when an upgrade condition associated with the outgoing queue of buffered streaming content is satisfied, switching to a media stream at a higher bitrate relative to the first bitrate for streaming to the streaming client, wherein the sender-based adaptive bitrate control operations are performed for the plurality of streaming clients without receiving any quality feedback from the plurality of streaming clients and without measuring bandwidth of a network channel for streaming to the plurality of streaming clients.

[0084] Example 2 includes the subject matter of Example 1, and further specifies that the sender-based adaptive bitrate control operations are performed for the plurality of streaming clients based only on sender-side monitoring of an outgoing queue of buffered streaming content.

[0085] Example 3 includes the subject matter of any of Examples 1-2, and further specifies that the downgrade condition is at least partially satisfied when a fullness of the outgoing queue of buffered streaming content is above a threshold.

[0086] Example 4 includes the subject matter of Example 3, and further specifies that the threshold depends on whether prior monitoring results indicate network instability, and wherein the threshold is lower when the prior monitoring results indicate network instability.

[0087] Example 5 includes the subject matter of any of Examples 1-4, and further specifies that the operations further comprise, after switching to the lower bitrate media stream when the downgrade condition is satisfied, remaining in a downgrade state for a period of time, wherein bitrate switching is not performed while in the downgrade state.

[0088] Example 6 includes the subject matter of Example 5, and further specifies that the operations further comprise, after the period of time has expired, moving to a monitoring state in which bitrate switching is allowed based on results of the monitoring.

[0089] Example 7 includes the subject matter of any one of Examples 1-6, and further specifies that the upgrade condition is satisfied at least in part when the fullness of the outgoing queue of the cached streaming content is below a threshold and when a probe interval is reached.

[0090] Example 8 includes the subject matter of Example 7, and further specifies that the probe interval is a variable length of time that increases when a failed upgrade operation occurs.

[0091] Example 9 includes the subject matter of any one of Examples 7-8, and further specifies that the probe interval is reset to a starting value when the media stream has been streamed without a failed upgrade operation for a reset period.

[0092] Example 10 includes the subject matter of any one of Examples 7-9, and further specifies that the threshold depends on whether previous monitoring results indicated network instability, and wherein the threshold is lower when the previous monitoring results indicated network instability.

[0093] Example 11 includes the subject matter of any one of Examples 1-10, and further specifies that the operations further include, after switching to the higher bit rate media stream when the upgrade condition is met, remaining in an upgrade state until a first occurrence of: expiration of a time period during which no bit rate switching is performed; or detection of network instability, at which time entering a recovery upgrade state and bit rate is restored to the first bit rate.

[0094] Example 12 includes the subject matter of any one of Examples 1-11, and further specifies that determining whether the upgrade condition or the downgrade condition is met for a given streaming client is based only on monitoring of an outgoing queue of streaming content for the given streaming client, and the media stream is streamed to each of the plurality of streaming clients via a lossless protocol.

[0095] Example 13 is a method implemented by a computing device for low-latency streaming of media content, the method comprising: performing sender-based adaptive bitrate control operations for each of a plurality of streaming clients, including: streaming a media stream comprising encoded video data to a streaming client at a first bitrate; monitoring an outgoing queue of buffered streaming content to be sent to the streaming client; based at least in part on the monitoring, when a downgrade condition associated with the outgoing queue of buffered streaming content is satisfied, switching to a media stream at a lower bitrate relative to the first bitrate for streaming to the streaming client; and based at least in part on the monitoring, when an upgrade condition associated with the outgoing queue of buffered streaming content is satisfied, switching to a media stream at a higher bitrate relative to the first bitrate for streaming to the streaming client; wherein the sender-based adaptive bitrate control operations are performed for the plurality of streaming clients without receiving any quality feedback from the plurality of streaming clients and without measuring bandwidth of a network channel for streaming to the plurality of streaming clients.

[0096] Example 14 includes the subject matter of Example 13, and further specifies that the sender-based adaptive bitrate control operations are performed for the plurality of streaming clients based only on sender-side monitoring of the outgoing queue of buffered streaming content.

[0097] Example 15 includes the subject matter of any of Examples 13-14, and further specifies that the downgrade condition is satisfied at least in part when a fullness of the outgoing queue of buffered streaming content is above a threshold.

[0098] Example 16 includes the subject matter of any of Examples 13-15, and further specifies that the method further comprises: after switching to the lower bitrate media stream when the downgrade condition is satisfied, remaining in a downgrade state for a period of time, wherein no bitrate switching is made while in the downgrade state; and after the period of time expires, moving to a monitoring state in which bitrate switching is allowed based on results of the monitoring.

[0099] Example 17 includes the subject matter of any of Examples 13-16, and further specifies that the upgrade condition is satisfied at least in part when a fullness of the outgoing queue of buffered streaming content is below a threshold and when a probe interval is reached.

[0100] Example 18 includes the subject matter of any one of Examples 13-17, and further specifies that the method further comprises, after switching to the higher bit rate media stream when the upgrade condition is satisfied, remaining in an upgrade state until a first occurrence of: expiration of a time period during which no bit rate switching is performed; or a network instability is measured, at which time entering a resume upgrade state and resuming the bit rate to the first bit rate.

[0101] Example 19 is one or more computer-readable storage media storing computer-executable instructions for execution on a computing device to perform operations for low latency streaming of media content, the operations comprising: performing sender-based adaptive bit rate control operations for each of a plurality of streaming clients, including: while in a monitoring state: streaming a media stream comprising encoded video data to a streaming client at a first bit rate; monitoring an outgoing queue of buffered streaming content to be sent to the streaming client; based at least in part on the monitoring, when a downgrade condition associated with the outgoing queue of buffered streaming content is satisfied, transitioning to a downgrade state to switch to a media stream at a lower bit rate relative to the first bit rate for streaming to the streaming client; and based at least in part on the monitoring, when an upgrade condition associated with the outgoing queue of buffered streaming content is satisfied, transitioning to an upgrade state to switch to a media stream at a higher bit rate relative to the first bit rate for streaming to the streaming client; while in the downgrade state: remaining in the downgrade state during a downgrade freeze interval during which no bit rate changes are made; and upon expiration of the downgrade freeze interval, transitioning to the monitoring state; and while in the upgrade state: based at least in part on the monitoring of the outgoing queue of buffered streaming content, when a resume upgrade condition associated with the outgoing queue of buffered streaming content is satisfied, transitioning to a resume upgrade state that resumes to the first bit rate; and when a resume step condition is not satisfied, and upon expiration of a step freeze interval during which no bit rate changes are made, transitioning to the monitoring state; wherein the sender-based adaptive bit rate control operations are performed for the plurality of streaming clients without receiving any quality feedback from the plurality of streaming clients and without measuring bandwidth of a network channel for streaming to the plurality of streaming clients.

[0102] Example 20 includes the subject matter of Example 19, and further specifies that the sender-based adaptive bitrate control operation further includes, while in the resume-upgrade state: resuming to the first bitrate; after resuming to the first bitrate, remaining in the resume-upgrade state during a downgrade freeze interval following the probe, wherein no bitrate changes are made during the downgrade freeze interval following the probe; and after expiration of the downgrade freeze interval following the probe, transitioning to the monitor state.

[0103] Computing system

[0104] Figure 5 A generalized example of a suitable computing system (500) on which the described techniques can be implemented is depicted. The computing system (500) is not intended to suggest any limitation as to scope or functionality, as such techniques can be implemented across a variety of computing systems and devices, from a general purpose computing system to a special purpose computing system.

[0105] With reference to Figure 5 The computing system (500) includes a bus (510), processing unit(s) (510), memory (520), storage (530), and numerous other elements and features, all of which are not shown for the sake of brevity. Figure 5 The bus (510) facilitates communication across the various components from the memory (520), processing unit(s) (510), storage (530), and numerous other elements and features, all of which are not shown for the sake of brevity. Figure 5 The processing unit(s) (510) executes instructions, codes, computer-readable languages and performs processing. The processing unit(s) can be a general purpose central processing unit (CPU), processor in an application-specific integrated circuit (ASIC), or any other type of processing unit. Depending on the exact configuration and type of processing unit(s), the memory (520) can be volatile (such as random access memory (RAM)), non-volatile (such as read-only memory (ROM), flash memory, etc.), or some combination of the two. The processing unit(s) (510) is configured to execute computer-readable instructions stored in the memory (520) to implement techniques described herein.

[0106] The computing system can have additional features. For example, the computing system (500) includes storage (530), one or more input devices (550), one or more output devices (560), and one or more communication connections (570). An interconnection mechanism (not shown) such as a bus, controller, or network interconnects the components of the computing system (500). Typically, operating system software (not shown) provides an operating environment for other software executing in the computing system (500), and coordinates activities of the components of the computing system (500).

[0107] The tangible storage 540 can be removable or non-removable, and includes magnetic disks, magnetic tapes or cassettes, CD-ROMs, DVDs, or any other medium that can be used to store information and that can be accessed within the computing system 500. The storage 540 stores instructions for the software 580 implementing one or more of the techniques described herein.

[0108] The input device(s) 550 can be a touch input device such as a keyboard, mouse, pen, or trackball, a voice input device, a scanning device, or another device that provides input to the computing system 500. For video encoding, the input device(s) 550 can be a camera, video card, TV tuner card, or similar device that accepts video input in analog or digital form, or a CD-ROM or CD-RW that reads video samples into the computing system 500. The output device(s) 560 can be a display, printer, speaker, CD-writer, or another device that provides output from the computing system 500.

[0109] The communication connection(s) 570 enable communication over a communication medium to another computing entity. The communication medium conveys information such as computer-executable instructions, audio or video input or output, or other data in a modulated data signal. A modulated data signal is a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media can use an electrical, optical, RF, or other carrier.

[0110] The techniques can be described in the general context of computer- executable instructions, such as those included in program modules, being executed in a computing system on a target real or virtual processor. Generally, program modules include routines, programs, libraries, objects, classes, components, data structures, etc. that perform particular tasks or implement particular abstract data types. Computer-executable instructions for program modules can be executed within the local or distributed computing system.

[0111] The terms “system” and “device” are used interchangeably herein. Unless the context clearly indicates otherwise, neither term implies any limitation on the types of computing systems or computing devices. In general, computing systems or computing devices can be local or distributed, and can include special-purpose hardware and / or general-purpose hardware in combination with software that implements the functionality described herein.

[0112] For the sake of presentation, the detailed description uses terms like “determine” and “use” to describe computer operations in a computing system. These terms are high-level abstractions for the operations of a computer that are performed by the computer and should not be conflated with acts performed in the human realm, even if performed by humans. The actual computer operations corresponding to these terms vary depending on implementation.

[0113] Cloud Support Environment

[0114] Figure 6 A generalized example of a suitable cloud-supported environment 600 in which described embodiments, techniques, and technologies can be implemented is shown. In the example environment 600, a cloud 610 provides various types of services (e.g., computing services). For example, the cloud 610 can include a collection of computing devices, which can be located centrally or in distributed locations, that provide cloud-based services to various types of users and devices connected via a network such as the Internet. The implementation environment 600 can be used to accomplish computing tasks in different ways. For example, some tasks (e.g., processing user input and presenting user interfaces) can be performed on local computing devices (e.g., connected devices 630, 640, 650), while other tasks (e.g., storage of data to be used in subsequent processing) can be performed in the cloud 610.

[0115] In the example environment 600, the cloud 610 provides services for connected devices 630, 640, 650 having various screen capabilities. The connected device 630 represents a device having a computer screen 635 (e.g., a medium-sized screen). For example, the connected device 630 can be a personal computer, such as a desktop computer, a laptop computer, a notebook, a netbook, etc. The connected device 640 represents a device having a mobile device screen 645 (e.g., a small-sized screen). For example, the connected device 640 can be a mobile phone, a smart phone, a personal digital assistant, a tablet computer, etc. The connected device 650 represents a device having a large screen 655. For example, the connected device 650 can be a television screen (e.g., a smart television) or another device connected to a television (e.g., a set-top box or a game console), etc. One or more of the connected devices 630, 640, 650 can include touch screen capabilities. Touch screens can accept input in different ways. For example, a capacitive touch screen detects touch input when an object (e.g., a fingertip or a stylus) distorts or interrupts an electrical current flowing on a surface. As another example, a touch screen can use optical sensors to detect touch input when a beam of light from an optical sensor is interrupted. Physical contact with the surface of the screen is not necessary for input to be detected by some touch screens. Devices without screen capabilities can also be used in the example environment 600. For example, the cloud 610 can provide services for one or more computers (e.g., server computers) that do not have displays.

[0116] The services can be provided by the cloud 610 through a service provider 620 or through other providers (not shown) of online services. For example, the cloud services can be customized for the screen size, display capabilities, and / or touch screen capabilities of a particular connected device (e.g., connected devices 630, 640, 650).

[0117] In the example environment 600, the cloud 610 provides the technology and solutions described herein to various connected devices 630, 640, 650, at least in part using a service provider 620. For example, the service provider 620 can provide a centralized solution for various cloud-based services. The service provider 620 can manage service subscriptions for users and / or devices (e.g., the connected devices 630, 640, 650 and / or their respective users).

[0118] Example Implementations

[0119] Although the operations of some of the disclosed methods are described in a particular, sequential order for convenience, it should be understood that this manner of description encompasses reordering unless a particular ordering is required by specific language. For example, depending on the function or functions facilitated by a particular method, reordering or simultaneous performance of operations described as sequential can be appropriate. Furthermore, some of the described operations would be performed sequentially in other methods, although not described within that method. In other examples, operations reordering or simultaneous performance of operations described as sequential can be inappropriate, depending on the function or functions facilitated by a particular method.

[0120] Any of the disclosed methods can be implemented as computer-executable instructions or a computer program product stored on one or more computer-readable storage media and executed on a computing device (i.e., any available computing device, including a smart phone or other mobile device that includes computing hardware). Computer-readable storage media are tangible media that can be accessed within a computing environment (one or more optical media discs such as DVD or CD, volatile memory such as DRAM or SRAM, or non-volatile memory such as flash memory or hard drives). By way of example, and not limitation, computer-readable storage media include memory 520 and 525 and storage 540. The term computer- readable storage media does not include signals and carrier waves. Figure 5

[0121] Any computer-executable instructions for implementing the disclosed technology, as well as any data created and used during implementation of the disclosed embodiments, can be stored on one or more computer-readable storage media. The computer-executable instructions can be part of, for example, a dedicated software application or part of a software application that is accessed or downloaded via a web browser or other software application (such as a remote computing application). Such software can be executed, for example, on a single local computer (e.g., any suitable commercially available computer) or in a network environment (e.g., via the Internet, a wide-area network, a local-area network, a client-server network (such as a cloud computing network), or other such network) using one or more network computers.

[0122] ​For clarity, only certain selected aspects of the software-based implementations are described. Other details that are well known in the art are omitted. For example, it should be understood that the disclosed technology is not limited to any particular computer language or program. For instance, the disclosed technology can be implemented by software written in C++, Java, Perl, or any other suitable programming language. Likewise, the disclosed technology is not limited to any particular computer or type of hardware. Certain details of suitable computers and hardware are well known and need not be set forth in detail in this disclosure.

[0123] Furthermore, any software-based embodiments (including at least one software-based embodiment for making a computer execute any of the disclosed methods) can be uploaded, downloaded, or remotely accessed through a suitable communication means. Such suitable communication means include, for example, the Internet, the World Wide Web, an intranet, software applications, cable (including fiber optic cable), magnetic communications, electromagnetic communications (including RF, microwave, and infrared communications), electronic communications, or other such communication means.

[0124] The disclosed methods, apparatus, and systems should not be construed as limiting in any way. Instead, the present disclosure is directed toward all novel and nonobvious features and aspects of the various disclosed embodiments, alone and in various combinations and subcombinations with each other. The disclosed methods, apparatus, and systems are not limited to any particular aspect or feature or combination of aspects and features, nor do the disclosed embodiments require that any one or more specific advantages be present or problems be solved.

[0125] The technology from any example can be combined with the technology described in any one or more other examples. In view of the many possible embodiments to which the principles of the disclosed technology can be applied, it should be recognized that the embodiments are examples of the disclosed technology and should not be considered as limiting the scope of the disclosed technology.

Claims

1. A computing device comprising: a processor; a network interface; and a memory; the computing device configured to perform operations for low-latency streaming of media content, the operations comprising: performing, for each of a plurality of streaming clients, sender-based adaptive bitrate control operations, including: streaming, to a streaming client, a media stream comprising encoded video data at a first bitrate; monitoring an outgoing queue of buffered streaming content to be sent to the streaming client; based at least in part on the monitoring, when a downgrade condition associated with the outgoing queue of buffered streaming content is satisfied, switching to a media stream at a lower bitrate relative to the first bitrate for streaming to the streaming client; and based at least in part on the monitoring, when an upgrade condition associated with the outgoing queue of buffered streaming content is satisfied, switching to a media stream at a higher bitrate relative to the first bitrate for streaming to the streaming client, wherein the upgrade condition is at least partially satisfied when fullness of the outgoing queue of buffered streaming content is below a threshold and when a probe interval is reached, and wherein the probe interval is a variable length of time that increases when a failed upgrade operation occurs such that a longer period of time relative to a previous upgrade operation is used before a subsequent upgrade operation is performed to again increase the bitrate; wherein the sender-based adaptive bitrate control operations are performed for the plurality of streaming clients without receiving any quality feedback from the plurality of streaming clients and without measuring bandwidth of a network channel for streaming to the plurality of streaming clients. The sender-based adaptive bitrate control operations are performed for the plurality of streaming clients based only on sender-side monitoring of the outgoing queue of buffered streaming content.

2. The computing device of claim 1, wherein, The downgrade condition is at least partially satisfied when fullness of the outgoing queue of buffered streaming content is above another threshold.

3. The computing device of claim 1, wherein, The other threshold depends on whether a previous monitoring result indicated network instability, and wherein the other threshold is lower when the previous monitoring result indicated network instability.

4. The computing device of claim 3, wherein, 5. The computing device of claim 1, the operations further comprising: after switching to the media stream at the lower bitrate when the downgrade condition is satisfied, remaining in a downgrade state for a period of time, wherein bitrate switching is not performed while in the downgrade state.

6. The computing device of claim 5, the operations further comprising: after the period of time has expired, moving to a monitoring state in which bitrate switching is allowed based on results of the monitoring. The probe interval is reset to a starting value when a media stream has been streamed without a failed upgrade operation for a reset period.

7. The computing device of claim 1, wherein, The threshold depends on whether a previous monitoring result indicated network instability, and wherein the threshold is lower when the previous monitoring result indicated network instability.

8. The computing device of claim 1, wherein, ​ 9. The computing device of claim 1, the operations further comprising: after switching to the media stream at the higher bit rate when the upgrade condition is met, remaining in an upgrade state until a first occurrence of: expiration of a time period, wherein no bit rate switching is performed during the time period; or detecting network instability, at which time entering a recover upgrade state and bit rate is recovered to the first bit rate.

10. The computing device of claim 1, wherein, determining whether an upgrade condition or a downgrade condition is met for a given streaming client based only on monitoring of an outgoing queue of the streaming content for the given streaming client, and wherein the media stream is streamed to each of the plurality of streaming clients via a lossless protocol.

11. A method implemented by a computing device for low-latency streaming of media content, the method comprising: performing a sender-based adaptive bit rate control operation for each of a plurality of streaming clients, including: streaming a media stream comprising encoded video data to a streaming client at a first bit rate; monitoring an outgoing queue of buffered streaming content to be sent to the streaming client; based at least in part on the monitoring, when a downgrade condition associated with the outgoing queue of buffered streaming content is met, switching to a media stream at a lower bit rate relative to the first bit rate for streaming to the streaming client, wherein the downgrade condition is at least partially met when fullness of the outgoing queue of buffered streaming content is above a threshold, wherein the threshold depends on whether a previous monitoring result indicated network instability, and wherein the threshold is lower when the previous monitoring result indicated network instability; and based at least in part on the monitoring, when an upgrade condition associated with the outgoing queue of buffered streaming content is met, switching to a media stream at a higher bit rate relative to the first bit rate for streaming to the streaming client; wherein the sender-based adaptive bit rate control operation is performed for the plurality of streaming clients without receiving any quality feedback from the plurality of streaming clients and without measuring bandwidth of a network channel for streaming to the plurality of streaming clients.

12. The method of claim 11, wherein, The sender-based adaptive bit rate control operation is performed for the plurality of streaming clients based only on sender-side monitoring of the outgoing queue of buffered streaming content.

13. The method of claim 11, wherein, The sender-based adaptive bit rate control operation further comprises: after switching to the media stream at the lower bit rate when the downgrade condition is met, remaining in a downgrade state for a period of time, wherein no bit rate switching is performed while in the downgrade state.

14. The method of claim 13, wherein, The sender-based adaptive bit rate control operation further comprises: after the period of time has expired, moving to a monitoring state in which bit rate switching is allowed based on results of the monitoring. The sender-based adaptive bit rate control operation further comprises: after switching to the media stream at the higher bit rate when the upgrade condition is met, remaining in an upgrade state until a first occurrence of: expiration of a time period, wherein no bit rate switching is performed during the time period; or detecting network instability, at which time entering a recover upgrade state and bit rate is recovered to the first bit rate.

15. One or more computer-readable storage media storing computer-executable instructions for execution on a computing device to perform operations for low-latency streaming of media content, the operations comprising: performing, for each of a plurality of streaming clients, sender-based adaptive bitrate control operations, including: while in a monitoring state: streaming a media stream comprising encoded video data to a streaming client at a first bitrate; monitoring an outgoing queue of buffered streaming content to be sent to the streaming client; based at least in part on the monitoring, when a downgrade condition associated with the outgoing queue of buffered streaming content is satisfied, transitioning to a downgraded state to switch to a media stream at a lower bitrate relative to the first bitrate for streaming to the streaming client; and based at least in part on the monitoring, when an upgrade condition associated with the outgoing queue of buffered streaming content is satisfied, transitioning to an upgraded state to switch to a media stream at a higher bitrate relative to the first bitrate for streaming to the streaming client, wherein the upgrade condition is at least partially satisfied when fullness of the outgoing queue of buffered streaming content is below a threshold and when a probe interval is reached, and wherein the probe interval is a variable length of time that increases upon occurrence of a failed upgrade operation such that a longer period of time relative to a previous upgrade operation is used before a subsequent upgrade operation is performed to again increase the bitrate; while in the downgraded state: remaining in the downgraded state during a downgrade freeze interval during which no bitrate changes are made; and upon expiration of the downgrade freeze interval, transitioning to the monitoring state; and while in the upgraded state: based at least in part on the monitoring of the outgoing queue of buffered streaming content, when a resume upgrade condition associated with the outgoing queue of buffered streaming content is satisfied, transitioning to a resume upgrade state that resumes to the first bitrate; and when the resume upgrade condition is not satisfied, and upon expiration of an upgrade freeze interval during which no bitrate changes are made, transitioning to the monitoring state; wherein the sender-based adaptive bitrate control operations are performed for the plurality of streaming clients without receiving any quality feedback from the plurality of streaming clients and without measuring bandwidth of a network channel for streaming to the plurality of streaming clients.

Images