In media distribution over an IP network, such as video and TV distribution over the Internet, the bandwidth to a client device will vary depending on various circumstances. When accessing the distributed media content over a mobile data network or a Wi-Fi network the capacity is shared between client devices. Further, individual client devices might enter locations with weaker or stronger signal affecting the bandwidth received by the client.
Today, variation in bandwidth as conceived by the client device is typically handled by three mechanisms: congestion control mechanisms of TCP (transmission control protocol of the TCP/IP protocol stack), buffering, and adjusting the video bitrate (ABR). Basically, congestion control is handled by the TCP protocol stack which adjusts the retransmission rate of lost packets to adapt the client device to use a fair share of the available bandwidth in the network (or actually in the bottleneck of the transmission). In such system, the client device needs to buffer data since it is not certain the network can offer enough bandwidth required by the video stream. In order to maintain the viewer experience the client device needs to have video data to present, so buffering is needed to absorb variances in bitrate introduced by the network, specifically by the TCP congestion avoidance mechanisms and the jitter introduced by the network. As the capacity and jitter varies in the IP network, the receiving client device must pause the presentation of the current video on the screen to accumulate more video data in its buffer. The accumulation is one method, meaning that the delay will increase and not decrease for a specific session. Such adjustments will introduce delay and the video cannot be considered live distribution due to the added delay.
According to the European Broadcasting Union, EBU, which defines TV standards in Europe, live TV is defined as a broadcasting delay from the ingress to the client device display or screen lower than seven seconds. Delay caused by the adjustments above may however end up in several minutes of delay.
More specifically, one of the most common ways to distribute video over the Internet is to use HLS (HTTP Live Streaming) or MPEG-DASH where the video stream is divided into typically 10 second (2-10 sec) video files (segments) making the linear video stream a series of 10 second video files. Every stream is typically represented by several bitrates (different video qualities), each being segmented into equivalent segment files. The client device then requests these files using normal http technology. To ensure that the client device always has video data to present, at least 3 time wise consecutive files are buffered in the device. This means that buffering will impose at least 30 seconds of delay. At start-up the buffer is filled up to a certain level, typically 30 seconds, corresponding to three 10 second segments. If packets are lost, the transport protocol TCP used by the HTTP protocol requests the data again and if uncertain if it can recover the whole segment file, also reduces the bitrate on outgoing traffic by requesting the next corresponding segment file of a lower bitrate to avoid congestion.
Over IP networks the bandwidth of a distributed video, i.e. the encoded bitrate of the video, is adjusted to the bandwidth available in the network to the client device. The video is encoded in different predefined bitrates (i.e. the level of compression of the video is differentiated, which in turn provides different quality levels of the video). This is typically done by a transcoding system which takes in an encoded video stream and then “re-encodes” it into one or several video streams with different bitrates, qualities and formats for different devices. The network system decides which encoded bitrate is applicable for the specific moment and selects the most suitable video quality to transfer to the client. In existing solutions, ABR adjustments, i.e. adjustment of the video bitrate/quality, are done based on the fill level of the buffer of the client device. More particularly, the decision to change to another encoded bitrate is done by monitoring the buffer fill level in the client device. A decreasing fill level indicates that the bandwidth of the network is lower than needed and the system needs to select a video with lower quality. Shifting to a higher quality video stream is done by simply testing a higher video bit rate and watching if the buffer fill level decreases. If it decreases, the system needs to go back to a lower video bit rate. This means that there will be continuous changes in ABR levels during the operation with the exception if the system is running on the highest ABR level and the buffer is not becoming empty. To avoid glitches in the video when changing between bit streams of different bit rates, the change is performed between segments, i.e. one start using the corresponding new segment of the new bitrate stream.
Although this approach to perform ABR adjustments of video by monitoring the buffer fill level may be applicable for video on demand services, there is a need for an improved method to perform ABR adjustments for video in IP network systems since the buffering of multiple segments at the device and possibly also in edge caches, and also the continuous adjustments of the ABR level increases the buffer fill level at the device, thereby increasing the delay before the video is displayed in the device. The accumulated delay happens because imperfections of using TCP to determine the network bit rate (which continuously is changing) force the client device to buffer more video data to avoid the buffer to run empty which in turn disrupts the video presentation. Typically, today's OTT systems start with an initial delay of 30-60 seconds depending on encoding delay, segment sizes, distribution network and client player implementation. This accumulates over time and e.g., the HLS protocol allows a client to buffer up to 15 minutes.