Sender-based adaptive bitrate control

Abstract

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

Description

Background Art

[0001] Media streaming solutions for media content use lossless network protocols to deliver media 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 result in high or very high delays depending on 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 real-time media stream by a corresponding amount. In addition, head-of-line blocking and TCP congestion control algorithms can increase the delay of networks that encounter problems (e.g., congestion or network packet loss).

[0002] With typical adaptive bitrate streaming techniques, a streaming client decides which bitrate stream to request based on the 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 of the invention

[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 to limit the scope of the claimed subject matter.

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

[0005] As another example, a sender-based adaptive bitrate control operation is performed for each of a plurality of streaming clients. The operation includes: when in a monitoring state: streaming a media stream including encoded video data to a streaming client at a first bitrate; monitoring an outgoing queue of cached streaming content to be sent to the streaming client; based at least in part on the monitoring, when a degradation condition is met, transitioning to a degradation state to switch to a media stream with a lower bitrate for streaming to the streaming client; and based at least in part on the monitoring, when an upgrade condition is met, transitioning to an upgrade state to switch to a media stream with a higher bitrate for streaming to the streaming client. The operation also includes, when in the degradation state: remaining in the degradation state within a degradation freeze interval, not making a bitrate change during the degradation freeze interval, and transitioning to the monitoring state when the degradation freeze interval expires. The operations also include, while in the upgrading state: transitioning to a resume upgrading state in which the content is restored to the first bit rate based at least in part on monitoring an outgoing queue of the cached streaming content when a resume upgrading condition is met, and transitioning to a monitoring state when the resume upgrading condition is not met and upon expiration of an upgrade freeze interval in which no bit rate change is made. Performing sender-based adaptive bitrate control operations for the plurality of streaming clients without receiving any quality feedback from the plurality of streaming clients and without measuring a bandwidth of a network channel used for streaming to the plurality of streaming clients. BRIEF DESCRIPTION OF THE 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 chart 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 chart 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 may be implemented.

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

[0012] Overview

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

[0014] In a typical streaming solution, the streaming protocol relies on the client to calculate the available bandwidth based on the speed at which the file fragments are downloaded. 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 that sends the media stream to the client). This approach takes a lot 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 may be difficult or impossible to measure network bandwidth by observing the data stream, because data is sent to the network at the rate at which it is produced. Therefore, the rate at which it is received does not necessarily indicate the available bandwidth. If data is sent at a higher rate, the network may (or may not) support the higher rate.

[0016] Technology described herein provides various advantages for the streaming of media content (e.g., for the low-delay streaming of media content). In general, these technologies provide a solution based on the sender (also referred to as a sender-side solution), which efficiently detects when congestion occurs in a network channel, and reacts by reducing the bit rate (e.g., by switching to a lower bit rate stream). On the contrary, when network congestion is not detected in a network channel, these technologies periodically test whether the bit rate can be increased (e.g., by switching to a higher bit rate stream). Technology described herein detects when congestion occurs or congestion may occur by the outgoing queue of the streaming content of the monitoring buffer (e.g., by only monitoring the outgoing queue of the streaming content of the buffer).

[0017] Sender-based solutions provide this automatic bitrate control without receiving any quality feedback from the streaming client and without measuring the bandwidth of the network channel used 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 streaming with reduced latency because a sender (e.g., a streaming service) does not need to wait for feedback from a streaming client when automatically adjusting the bitrate. For example, a sender can detect congestion in a network channel based solely on an outgoing queue at the sender (e.g., by measuring its fullness) and quickly drop to a lower bitrate 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 bitrate decisions for many streaming clients based solely on the outgoing queue and without receiving any quality feedback from the streaming clients. For example, since the sender does not receive or process quality feedback from the streaming clients, network and computing resources are saved.

[0020] These solutions allow a sender (e.g., a streaming service) to automatically select the highest bitrate stream that fits the available bandwidth. For example, the sender reduces the bitrate when the outgoing queue indicates congestion, and attempts to increase the bitrate (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 a sender (e.g., a streaming service) to minimize playback stalls. Playback stalls are minimized by quickly and efficiently detecting congestion and switching (e.g., immediately switching) to a lower bitrate stream. Similarly, when attempting to increase the bitrate, congestion can be quickly detected and the bitrate increase can be restored (e.g., by immediately switching back).

[0022] These solutions also allow manual control of the bitrate. For example, the 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. The client can later switch back to a sender-side adaptive rate control solution if needed.

[0023] The techniques described herein can be used to efficiently (e.g., with low overhead) stream audio and / or video content to a streaming client 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 may 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 insight 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 Ser. No. 17 / 670,148, filed on February 11, 2022, and entitled “ULTRA-LOW LATENCY VIDEO STREAMING.”

[0026] the term

[0027] The term "media content" refers to encoded audio and / or video content. The encoded audio and / or video content comprises 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 a corresponding audio and / or video codec.

[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, the media stream can be streamed from a streaming service to one or more streaming clients via one or more corresponding network channels.

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

[0030] The term "semi-lossless protocol" refers to one or more network protocols that provide semi-reliable data transmission from a first computing device (e.g., a server) to a second computing device (e.g., a client) over a computer network. 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, a tablet computer, a smart phone, or another type of computing device) that decodes and presents (e.g., via audio and / or video playback) the received media streams.

[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., streamed to multiple streaming clients). A sender can also be another type of computing device and / or software solution (e.g., a desktop computer, a laptop computer, a smart phone, or another type of computing device that runs software that streams audio and / or video data to one or more streaming clients).

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

[0034] Example media stream and outgoing queue

[0035] In the technology described herein, media content is delivered to a client as a media stream (e.g., as a real-time media stream or as another type of media stream). For example, the media content of the media stream can be used for real-time delivery to the client. Due to 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 cached streaming content to be sent to 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 been sent to the given streaming client but has not yet been confirmed as received by the given streaming client. In some embodiments, 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 embodiments, application programming interface (API) calls or system calls are used to monitor the outgoing queues of cached streaming content (e.g., to determine how full they are or how much of the available buffer is occupied). The specific calls depend on the operating system and / or application being used. For example, when using The Windows Input / Output Completion Port (IOCP) API can be used when the operating system is running, and when using The Linux io_uring system call can be used when operating the system.

[0037] The fullness of an outgoing queue for cached streaming content refers to how much of the queue is available for adding streaming content relative to how much of the queue currently stores cached streaming content to be sent to streaming clients. The fullness metric can indicate a specific percentage of the outgoing queue that is currently occupied (e.g., in terms of total space in 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), then the given outgoing queue will be 40% full.

[0038] Environment for sender-based adaptive bitrate control

[0039] Figure 11 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. Example environment 100 includes a streaming service 110. Streaming service 110 provides media content for streaming to streaming clients including streaming clients 130, 132, and 134. In some embodiments, streaming service 110 uses a lossless protocol to stream media content to streaming clients, including streaming client 130, streaming client 132, and streaming client 134. 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. Although streaming service 110 is an example of a solution for performing sender-based adaptive bitrate control techniques described herein, other types of senders (e.g., other software and / or hardware solutions) can perform operations described with respect to streaming service 110.

[0040] The streaming service 110 performs various operations for streaming the media stream to the streaming clients, as shown at 112. For example, the operations may include a sender-based adaptive bitrate control operation, in which the bitrate is automatically adjusted by the streaming service 110 without receiving any quality feedback from the streaming clients (e.g., from the 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, streaming service 110 provides media streams to three streaming clients (streaming client 130, streaming client 132, and streaming client 134), as shown in 140. 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 the audio and / or video data of the encoding waiting to be delivered to its corresponding streaming client. For ease of explanation, example environment 100 depicts three streaming clients and their corresponding queues. However, example environment 100 supports any number of streaming clients and associated queues.

[0042] As depicted, each of the queues stores a certain amount of streaming content to be delivered to the streaming clients. For example, queue 120 currently contains a certain amount of streaming clients 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] The streaming service 110 can perform adaptive bitrate control operations by monitoring the queues (e.g., by monitoring queues 120, 122, and 124). For example, the streaming service 110 can monitor how full each queue is and reduce or increase the bitrate accordingly. In some implementations, the streaming service 110 performs a downgrade operation to reduce the bitrate when downgrade conditions are met, and performs an upgrade operation to increase the bitrate when upgrade conditions are met.

[0044] The streaming service 110 operates without using per-client quality feedback from the streaming clients (e.g., from the streaming clients 130, 132, and 134). For example, when the streaming service 110 performs an adaptive bitrate control operation, the 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 embodiments, the streaming service 110 uses only information about the queue when determining whether to adjust the bitrate.

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

[0046] Figure 2 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 the example state diagram 200.

[0047] Example state diagram 200 is used when monitoring an outgoing queue for buffered streaming content sent to a streaming client. In some embodiments, monitoring is performed before each frame or packet is sent to the outgoing queue, and state transitions may occur at this frequency. Other embodiments may monitor the queue on another periodic basis (e.g., based on the number of frames, the amount of streaming content, or the 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 monitoring returns when sender-based adaptive bitrate control is disabled and re-enabled. From the monitoring state 212, the bitrate for a 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) based on monitoring of the outgoing queue of the given client's cached streaming content.

[0049] While in the monitoring state 212, the streaming service monitors the status of the queue of cached streaming content. When a degradation condition is met 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 for streaming to the streaming client associated with the given queue by transitioning to the degraded state 210. As shown in 220, the degradation condition is at least partially determined by checking whether the network connection between the streaming service and the streaming client is unstable, and if the degradation condition is determined, the transition to the degraded state 210 is performed. In some embodiments, the degradation condition is met when the fullness of the outgoing queue of the cached 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 an unstable network condition (e.g., the network channel is congested or likely to become congested).

[0050] In some embodiments, determining whether a degradation condition is met for a given streaming client is based solely on monitoring of an outgoing queue of streaming content for the given streaming client (e.g., performed by monitoring state 212). In this way, the streaming service can efficiently perform adaptive bitrate 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.

[0051] While in the degraded state 210, the streaming 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 "degraded freeze interval". During this period of time while in the degraded state 210, no bit rate switching is performed (i.e., even if network instability is detected, the streaming service will not increase or decrease the bit rate during this period of time). As depicted at 222, after the degraded freeze interval has expired, the streaming service transitions back to the monitoring state 212, where a switching of the bit rate can now occur.

[0052] When in monitoring state 212, the streaming service monitors the status of the queue of cached 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 media stream for streaming to the streaming clients associated with the given queue by transitioning to upgrade state 214. In some embodiments, the upgrade condition is met when at least two criteria are met. The first is that the fullness of the outgoing queue of the cached streaming content is below a threshold (indicating that the network is stable). The second is that the detection interval has been reached. The detection interval is designed so that the monitoring service attempts to periodically increase the bit rate.

[0053] In some embodiments, determining whether the upgrade condition is met for a given streaming client is based solely on monitoring the outgoing queue of the streaming content for the given streaming client (e.g., performed by monitoring state 212). In this way, the streaming service can efficiently perform adaptive bitrate 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 shown in 224, and transitions to the upgrade state 214. The upgrade state 214 is a transition state that the streaming service enters when probing to determine whether the network will support a higher bit rate. When in the upgrade state 214, the status of the outgoing queue of the cached streaming content is monitored, and there are two possible transitions. First, if network instability is detected (for example, if the fullness of the queue is above a threshold), the streaming service transitions (for example, immediately transitions) to the recovery upgrade state 216, as shown in 225. This process allows the streaming service to detect the status of the network connection of the streaming client and try a higher bit rate stream, but if instability is detected after the switch (for example, immediately after the switch), the bit rate can be restored using the recovery upgrade state 216. If the recovery upgrade state 216 is entered, the monitoring service waits for a period of time for network congestion to resolve and the network to become stable. This period of time is called the "downgrade freeze interval after detection". During this time period, no bit rate switching is performed (i.e., the streaming service does not increase or decrease the bit rate during this time period, even if network instability is detected) while in the resume upgrade state 216. After the downgrade freeze interval after the probe has expired, as depicted at 228, the streaming service transitions back to the monitoring state 212, where switching of the bit rate can now occur.

[0055] If the network is stable (i.e., no network instability is detected by the monitoring queue) for a period of time called the "upgrade freeze interval," a second possible transition from the upgrade state 214 will occur. During this period, 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 a switch in bit rate can now occur.

[0056] In some embodiments, the downgrade freeze interval after the probe is selected to be longer (e.g., substantially longer) than the downgrade freeze interval. The reason why the downgrade freeze interval may be shorter is that the reason for the transition to the downgrade state 210 is a change in network conditions, which may have changed significantly and require further downgrade 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 may not be worse than they were before, and further downgrade is unlikely. Therefore, more time can be provided for resolving congestion before returning to the monitoring state 212.

[0057] In the technology 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 higher than the threshold, the network is considered unstable (i.e., network instability has been detected). Otherwise, the network is considered stable. In some embodiments, the threshold value changes depending on the previous monitoring results. For example, when the previous monitoring results indicate a stable network, a first threshold value is used. Otherwise, when the previous monitoring results indicate an unstable network, a second threshold value (different from the first threshold value) is used. In some embodiments, the second threshold value is lower than the first threshold value. As an example, the first threshold value may be 50% and the second threshold value may be 20% (e.g., indicating that 80% of the queue is empty). In this way, when the network was previously unstable, a stricter threshold value may be implemented for stability.

[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, regardless of what a direct measurement of the bandwidth might indicate.

[0059] In some embodiments, the probing interval increases as failed upgrade operations occur. Increasing the probing interval in this manner reduces the likelihood that the streaming client will experience video stalls. For example, if the streaming service attempts to increase the bit rate, but fails (e.g., by detecting network instability and transitioning to the recovery upgrade state 216), the streaming service increases the probing interval (e.g., exponentially) so that the streaming service waits for a longer period of time before probing the network again to determine whether it will support a higher bit rate. In some embodiments, 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 of the probe 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 increments on each failed upgrade operation. The "failed checks ceiling" value imposes an upper limit on the probe interval. To illustrate the probe interval calculation, if the check interval is 30 seconds, the failed check count is 3 (indicating three previously failed upgrade operations), and the failed check ceiling is 8, then the probe interval will be 240 seconds. In some embodiments, the probe interval is reset (by resetting the failed check count to zero) when the media stream has been successfully played and there have been no failed upgrade operations within a period of time called the failed check reset interval.

[0063] In some embodiments, 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 a manual override 230 conversion. When disabled, the streaming service enters a disabled state 218, in which the 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 the adaptive bit rate selection, the monitoring service switches back to the monitoring state 212, as shown at 232.

[0064] In some embodiments, when switching to a different bit rate, the switch does not occur immediately. Instead, 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, 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 alleviate congestion.

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

[0066]

[0067] Table 1 - Example parameters

[0068] In some embodiments, sender-based adaptive bitrate control operations are performed for multiple streaming clients (e.g., by a streaming service such as streaming service 110) based solely on sender-side monitoring of an outgoing queue of cached streaming content. For example, the streaming service uses a state diagram such as example state diagram 200 to perform adaptive bitrate control and manage transitions between states (including monitoring states, degraded states, upgrade states, resume upgrade states, disabled states, and / or other states that can be used to perform adaptive bitrate control). In this way, the streaming service can efficiently perform adaptive bitrate control without receiving any quality feedback from the streaming clients 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.

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

[0070] In any examples herein, a method for low-latency streaming of media content (e.g., using a lossless protocol) can be provided by performing a sender-based adaptive bitrate control operation. The sender-based adaptive bitrate control can be performed by monitoring an outgoing queue of cached streaming content, and performing a bitrate control operation (e.g., increasing or decreasing the bitrate) based on the results of the monitoring.

[0071] Figure 3 is a flow chart of an example method 300 for low-latency streaming of media content (eg, using a lossless protocol). Example method 300 may be performed by a streaming service such as streaming service 110, for example.

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

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

[0074] At 330, an outgoing queue of buffered streaming content to be sent to a streaming client is monitored. Monitoring may include evaluating the fullness of the queue (e.g., based on a percentage of the queue that is full or empty, based on a percentage of the allocated buffer that is utilized or unutilized, and / or based on other criteria that indicate how full or empty the queue is).

[0075] At 340, when a degradation condition associated with the outgoing queue of the cached streaming content is met, a switch to a lower bit rate media stream is performed for streaming to the streaming client. The lower bit rate media stream has a lower bit rate relative to the first bit rate (e.g., the first bit rate may be 2000 kbps and the lower bit rate may be 1200 kbps). At least in part, the degradation condition is met when the fullness of the outgoing queue of the cached streaming content is above a threshold. Other criteria may also be required to meet the degradation condition, such as, for example, the current bit rate is not the lowest possible bit rate.

[0076] At 350, when an upgrade condition associated with the outgoing queue of the cached streaming content is met, a switch to a higher bit rate media stream is performed for streaming to the streaming client. The higher bit rate media stream has a higher bit rate relative to the first bit rate. At least in part, the upgrade condition is met when the fullness of the outgoing queue of the cached streaming content is below a threshold and when a probing interval is reached. Other criteria may also be required to meet the upgrade condition, such as when the current bit rate is not the highest possible bit rate.

[0077] Figure 4 4 is a flow chart 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, by transitioning between states, a sender-based adaptive bitrate control operation (e.g., operations 411-434) is performed for each of the one or more streaming clients. In addition, the sender-based adaptive bitrate control operation is performed for the streaming clients without receiving any quality feedback from the streaming clients and without measuring the bandwidth of the network channel used for streaming to the streaming clients.

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

[0080] At 420, while in the degraded state, a sender-based adaptive bitrate control operation is performed. At 422, the streaming service remains in the degraded state for the 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, while in the upgrade state, a sender-based adaptive bitrate control operation is performed. While in the upgrade state, the queue is monitored for instability. At 432, based at least in part on the monitoring, when a resume upgrade condition associated with the outgoing queue of the cached streaming content is met, a transition to a resume upgrade state is performed, which resumes (e.g., immediately resumes) to a previous bitrate (e.g., to a first bitrate). In some embodiments, the resume upgrade condition is met when monitoring of the outgoing queue of the cached streaming content indicates that the fullness is above a threshold (e.g., as performed at 414). Otherwise (when the resume upgrade condition is not met), at 434, upon expiration of the upgrade freeze interval, a transition back to the monitoring state at 411 is performed.

[0082] Other embodiments

[0083] Example 1 is a computing device comprising: a processor, a network interface, and a memory, the computing device being configured to perform operations for low-latency streaming of media content. The operation includes: performing a sender-based adaptive bitrate control operation for each of a plurality of streaming clients, including: streaming a media stream including encoded video data to the streaming client at a first bitrate; monitoring an outgoing queue of cached streaming content to be sent to the streaming client; based at least in part on the monitoring, when a degradation condition associated with the outgoing queue of the cached streaming content is met, switching to a media stream with 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 the cached streaming content is met, switching to a media stream with a higher bitrate relative to the first bitrate for streaming to the streaming client; wherein the sender-based adaptive bitrate control operation is performed for the plurality of streaming clients without receiving any quality feedback from the plurality of streaming clients and without measuring the bandwidth of a network channel used for streaming to the plurality of streaming clients.

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

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

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

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

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

[0089] Example 7 includes the subject matter of any of Examples 1-6, and further specifies that the upgrade condition is at least partially satisfied when a fullness of an outgoing queue of 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 of Examples 7-8, and further specifies that the probing interval is reset to the starting value when the media stream has been streamed without a failed upgrade operation within the reset period.

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

[0093] Example 11 includes the subject matter of any of Examples 1-10, and further specifies that the operation also includes: after switching to a higher bit rate media stream when the upgrade condition is met, remaining in the upgrade state, and remaining in the upgrade state until the first occurrence of the following items: 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 the bit rate is restored to the first bit rate.

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

[0095] Example 13 is a method for low-latency streaming of media content implemented by a computing device, the method comprising: performing a sender-based adaptive bitrate control operation for each of a plurality of streaming clients, comprising: streaming a media stream comprising encoded video data to the streaming client at a first bitrate; monitoring an outgoing queue of cached streaming content to be sent to the streaming client; based at least in part on the monitoring, when a degradation condition associated with the outgoing queue of the cached streaming content is met, switching to a media stream with 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 the cached streaming content is met, switching to a media stream with a higher bitrate relative to the first bitrate for streaming to the streaming client; wherein the sender-based adaptive bitrate control operation is performed for the plurality of streaming clients without receiving any quality feedback from the plurality of streaming clients and without measuring the 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 performing sender-based adaptive bitrate control operations for multiple streaming clients based solely on sender-side monitoring of an outgoing queue of cached streaming content.

[0097] Example 15 includes the subject matter of any of Examples 13 to 14, and further specifies that the demotion condition is at least partially satisfied when a fullness of an outgoing queue of cached streaming content is above a threshold.

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

[0099] Example 17 includes the subject matter of any of Examples 13 to 16, and further specifies that the upgrade condition is at least partially satisfied when a fullness of an outgoing queue of cached streaming content is below a threshold and when a detection interval is reached.

[0100] Example 18 includes the subject matter of any one of Examples 13 to 17, and further specifies that the method further includes: after switching to the higher bitrate media stream when the upgrade condition is met, remaining in the upgrade state until the first occurrence of the following: expiration of a time period during which no bitrate switching is performed; or network instability is detected, at which time entering a recovery upgrade state and the bitrate is restored to the first bitrate.

[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 bitrate control operations for each of a plurality of streaming clients, comprising: 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 cached streaming content to be sent to the streaming client; based at least in part on the monitoring, when a degradation condition associated with the outgoing queue of the cached streaming content is met, transitioning to a degraded 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 the cached streaming content is met, transitioning to an upgraded state state to switch to a media stream of a higher bit rate relative to the first bit rate for streaming to a streaming client; when in the degraded state: remain in the degraded state during a degraded freeze interval during which no bit rate change is made; and when the degraded freeze interval expires, transition to the monitoring state; and when in the upgrade state: at least partially based on monitoring of an outgoing queue of the cached streaming content, when a recovery upgrade condition associated with the outgoing queue of the cached streaming content is met, transition to a resume upgrade state, the resume upgrade state being restored to the first bit rate; and when a recovery step condition is not met and when a step freeze interval without bit rate change expires, transition to the monitoring state; wherein sender-based adaptive bitrate control operations are performed for multiple streaming clients without receiving any quality feedback from the multiple streaming clients and without measuring the bandwidth of a network channel used for streaming to the multiple streaming clients.

[0102] Example 20 includes the subject matter of Example 19, and further specifies that the sender-based adaptive bitrate control operation also includes: when in the recovery upgrade state: recovering to the first bitrate; after recovering to the first bitrate, remaining in the recovery upgrade state during the downgrade freeze interval after detection, wherein no bitrate change is made during the downgrade freeze interval after detection; and after the downgrade freeze interval after detection expires, transitioning to the monitoring state.

[0103] Computing System

[0104] Figure 5 A generalized example of a suitable computing system 500 is depicted in which the described techniques may be implemented. Computing system 500 is not intended to suggest any limitation as to scope of use or functionality, as these techniques may be implemented in a variety of general-purpose or special-purpose computing systems.

[0105] refer to Figure 5 , the computing system 500 includes one or more processing units 510, 515 and memories 520, 525. Figure 5 , the basic configuration 530 is included within the dashed line. Processing units 510, 515 execute computer executable instructions. The processing unit may be a general-purpose central processing unit (CPU), a processor in an application-specific integrated circuit (ASIC), or any other type of processor. The processing unit may also include multiple processors. In a multi-processing system, multiple processing units execute computer executable instructions to increase processing power. For example, Figure 5 A central processing unit 510 and a graphics processing unit or co-processing unit 515 are shown. Tangible memory 520, 525 may be volatile memory (e.g., registers, cache, RAM), non-volatile memory (e.g., ROM, EEPROM, flash memory, etc.), or some combination of both accessible by the processing unit. The memory 520, 525 stores software 580 implementing one or more techniques described herein in the form of computer-executable instructions suitable for execution by the processing unit.

[0106] The computing system may have additional features. For example, the computing system 500 includes storage 540, 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 executed in the computing system 500 and coordinates the activities of the components of the computing system 500.

[0107] Tangible storage 540 may be removable or non-removable and include disks, tapes or cassettes, CD-ROMs, DVDs, or any other medium that can be used to store information and that can be accessed within computing system 500. Storage 540 stores instructions for software 580 that implement one or more techniques described herein.

[0108] Input device 550 may 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 computing system 500. For video encoding, input device 550 may 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 computing system 500. Output device 560 may be a display, printer, speaker, CD writer, or another device that provides output from computing system 500.

[0109] Communication connection 570 enables communication with another computing entity via a communication medium. The communication medium transmits 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 whose one or more characteristics are set or changed in a manner that encodes information in the signal. By way of example and not limitation, the communication medium may use electrical, optical, RF or other carrier waves.

[0110] The techniques may be described in the general context of computer executable instructions, such as included in program modules, executed in a computing system on a target real or virtual processor. Typically, program modules include routines, programs, libraries, objects, classes, components, data structures, etc. that perform specific tasks or implement specific abstract data types. In various embodiments, the functionality of program modules may be combined or split between program modules as needed. Computer executable instructions for program modules may be executed within a 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 type of computing system or computing device. In general, a computing system or computing device may be local or distributed, and may include any combination of special-purpose hardware and / or general-purpose hardware with software that implements the functionality described herein.

[0112] For presentation purposes, the detailed description uses terms such as "determine" and "use" to describe computer operations in a computing system. These terms are high-level abstractions for operations performed by a computer and should not be confused with actions performed by a human. The actual computer operations corresponding to these terms vary depending on the implementation.

[0113] Cloud Support Environment

[0114] Figure 6 A generalized example of a suitable cloud support environment 600 in which the described embodiments, techniques, and technologies may 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 may include a collection of computing devices that may be centrally located or distributed, which provide cloud-based services to various types of users and devices connected via a network such as the Internet. The implementation environment 600 may be used to complete computing tasks in different ways. For example, some tasks (e.g., processing user input and presenting a user interface) may be performed on a local computing device (e.g., connected devices 630, 640, 650), while other tasks (e.g., storage of data to be used in subsequent processing) may be performed in the cloud 610.

[0115] In the example environment 600, the cloud 610 provides services for connected devices 630, 640, 650 with various screen capabilities. The connected device 630 represents a device with 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 with 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 with a large screen 655. For example, the connected device 650 can be a TV screen (e.g., a smart TV) or another device connected to a TV (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. The touch screen 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 the current flowing on the surface. As another example, a touch screen can use an optical sensor to detect touch input when a light beam from the optical sensor is interrupted. Physical contact with the screen surface is not necessary for input to be detected by some touch screens. Devices without screen capabilities can also be used in example environment 600. For example, cloud 610 can provide services for one or more computers (e.g., server computers) without a display.

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

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

[0118] Example Implementations

[0119] Although the operations of some disclosed methods are described in a particular order for ease of presentation, it should be understood that such description includes rearrangement unless the specific language set forth below requires a particular ordering. For example, in some cases, the operations described in sequence may be rearranged or performed simultaneously. In addition, for simplicity, the accompanying drawings may not show the various ways in which the disclosed methods can be used in conjunction with other methods.

[0120] Any disclosed method may be implemented as computer executable instructions or computer program products stored on one or more computer readable storage media and executed on a computing device (i.e., any available computing device, including a smartphone or other mobile device that includes computing hardware). A computer readable storage medium is a tangible medium that can be accessed within a computing environment (one or more optical media disks, such as DVDs or CDs, volatile memory (such as DRAM or SRAM), or non-volatile memory (such as flash memory or a hard drive). As an example and with reference to Figure 5 , computer-readable storage media include memories 520 and 525 and storage device 540. The term computer-readable storage medium does not include signals and carrier waves. In addition, the term computer-readable storage medium does not include communication connections, such as 570.

[0121] Any computer executable instructions for implementing the disclosed technology and any data created and used during the implementation of the disclosed embodiments can be stored on one or more computer readable storage media. Computer executable instructions can be, for example, a dedicated software application or a part of a software application 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 networks) using one or more network computers.

[0122] For clarity, only certain selected aspects of the software-based implementation are described. Other details 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 example, the disclosed technology can be implemented by software written in C++, Java, Perl, or any other suitable programming language. Similarly, the disclosed technology is not limited to any particular computer or hardware type. Certain details of suitable computers and hardware are well known and do not need to be elaborated in this disclosure.

[0123] In addition, any software-based embodiments (including, for example, computer-executable instructions for causing a computer to perform any disclosed method) can be uploaded, downloaded, or remotely accessed via suitable communication means. Such suitable communication means include, for example, the Internet, the World Wide Web, an intranet, a software application, cables (including fiber optic cables), magnetic communications, electromagnetic communications (including RF, microwave, and infrared communications), electronic communications, or other such communications means.

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

[0125] The techniques from any example can be combined with the techniques 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 illustrated 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: processor; Network interface; as well as Memory; The computing device is configured to perform operations for low-latency streaming of media content, the operations comprising: Performing a sender-based adaptive bitrate control operation for each of a plurality of streaming clients includes: streaming a media stream including the encoded video data to a streaming client at a first bit rate; monitoring an outgoing queue of cached streaming content to be sent to the streaming client; Based at least in part on the monitoring, when a degradation condition associated with an outgoing queue of the cached streaming content is met, switching to a media stream of 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 an outgoing queue of the cached streaming content is satisfied, switching to a media stream of a higher bit rate relative to the first bit rate for streaming to the streaming client, wherein the upgrade condition is at least in part satisfied when a fullness of the outgoing queue of the cached streaming content is below a threshold and when a probing interval is reached, and wherein the probing interval is a variable length of time that increases when a failed upgrade operation occurs such that a longer period of time is used relative to a previous upgrade operation before a subsequent upgrade operation is performed to again increase the bit rate; The sender-based adaptive bitrate control operation is performed for the plurality of streaming clients without receiving any quality feedback from the plurality of streaming clients and without measuring a bandwidth of a network channel used for streaming to the plurality of streaming clients.

2. The computing device of claim 1, wherein: The sender-based adaptive bitrate control operation is performed for the plurality of streaming clients based solely on sender-side monitoring of an outgoing queue of the cached streaming content.

3. The computing device of claim 1, wherein: The degradation condition is at least partially satisfied when a fullness of an outgoing queue of the cached streaming content is above another threshold.

4. The computing device of claim 3, wherein: The further threshold depends on whether a previous monitoring result indicates network instability, and wherein the further threshold is lower when the previous monitoring result indicates network instability.

5. The computing device of claim 1, the operations further comprising: After switching to the media stream of the lower bit rate when the degradation condition is met, remaining in the degraded state for a period of time, wherein no bit rate switching is performed while in the degraded state.

6. The computing device of claim 5, the operations further comprising: After the period of time has expired, a move is made to a monitoring state in which bit rate switching is allowed based on the results of the monitoring.

7. The computing device of claim 1, wherein: When the media stream has been streamed without a failed upgrade operation within the reset period, the detection interval is reset to the starting value.

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

9. The computing device of claim 1, the operations further comprising: After switching to the higher bit rate media stream when the upgrade condition is met, remaining in the upgrade state until the first occurrence of: expiry of a time period during which no bit rate switching is performed; or When network instability is detected, the system enters a recovery upgrade state and the bit rate is restored 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 is based solely on monitoring 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 bitrate control operation for each of a plurality of streaming clients includes: streaming a media stream including the encoded video data to a streaming client at a first bit rate; monitoring an outgoing queue of cached streaming content to be sent to the streaming client; Based at least in part on the monitoring, when a degradation condition associated with the outgoing queue of the cached streaming content is met, switching to a media stream of a lower bit rate relative to the first bit rate for streaming to the streaming client, wherein the degradation condition is at least in part met when a fullness of the outgoing queue of the cached streaming content is above a threshold, wherein the threshold depends on whether a previous monitoring result indicates network instability, and wherein the threshold is lower when the previous monitoring result indicates network instability; and At least in part based on the monitoring, when an upgrade condition associated with an outgoing queue of the cached streaming content is met, switching to a media stream with a higher bit rate relative to the first bit rate for streaming to the streaming clients; wherein the sender-based adaptive bitrate control operation is performed for the multiple streaming clients without receiving any quality feedback from the multiple streaming clients and without measuring the bandwidth of a network channel used for streaming to the multiple streaming clients.

12. The method according to claim 11, wherein: The sender-based adaptive bitrate control operation is performed for the plurality of streaming clients based solely on sender-side monitoring of an outgoing queue of the cached streaming content.

13. The method according to claim 11, wherein: The sender-based adaptive bit rate control operation also includes: After switching to the media stream of the lower bit rate when the degradation condition is met, remaining in the degraded state for a period of time, wherein no bit rate switching is performed while in the degraded state.

14. The method according to claim 13, wherein: The sender-based adaptive bit rate control operation also includes: After the period of time has expired, a move is made to a monitoring state in which bit rate switching is allowed based on the results of the monitoring.

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 a sender-based adaptive bitrate control operation for each of a plurality of streaming clients includes: When in monitoring state: streaming a media stream including the encoded video data to a streaming client at a first bit rate; monitoring an outgoing queue of cached streaming content to be sent to the streaming client; Based at least in part on the monitoring, when a degrade condition associated with an outgoing queue of the cached streaming content is satisfied, transitioning to a degraded 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 the cached 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 a streaming client, wherein the upgrade condition is at least in part satisfied when a fullness of the outgoing queue of the cached streaming content is below a threshold and when a probing interval is reached, and wherein the probing interval is reset to a starting value when the media stream has been streamed without a failed upgrade operation within a reset period; While in the degraded state: remaining in the degraded state during a degrade freeze interval during which no bit rate change is made; and When the downgrade freeze interval expires, switching to the monitoring state; and When in the upgrade state: Based at least in part on monitoring the outgoing queue of the cached streaming content, when a resume upgrading condition associated with the outgoing queue of the cached streaming content is satisfied, transition to a resume upgrading state, the resume upgrading state resuming to the first bit rate; and When the resuming upgrade condition is not satisfied and when the upgrade freezing interval expires, switching to the monitoring state, wherein no bit rate change is performed during the upgrade freezing interval; The sender-based adaptive bitrate control operation is performed for the plurality of streaming clients without receiving any quality feedback from the plurality of streaming clients and without measuring a bandwidth of a network channel used for streaming to the plurality of streaming clients.

Images