0:33
Buffering does help a lot.
It can mask variations in the network's performance.
In fact even interactive applications like Skype
use buffering on the order of 100 milliseconds or so.
For streaming with the applications, several seconds of buffering is seen as
acceptable, because these aren't interactive.
You can fill up the buffer in the beginning, start playing smoothly.
And then the buffer covers up variations in the networks bandwidth.
So as the available bandwidth reduces.
The buffer drains a little bit, and as the bandwidth increases,
the buffer fills up again.
And hopefully you don't see the buffer empty.
And the stream plays smoothly.
But if the buffer does empty out, you have a pause in the playback, and
that hampers the video experience.
The common approach to solving this problem is as follows.
Video is encoded in multiple bit-rates.
For example, from lower resolution standard definition, or
SD, through various rates up to 102 for HD, or higher.
The video player at the client estimates the network connection's available
bandwidth.
It then picks a video rate that's slightly less than the available bandwidth.
So, the rate of incoming data over the network exceeds the rate of
the data playing out from the buffer onto the client's screen.
That's simple enough.
Right?
Let's look closer at how this is supposed to play out.
2:03
One can think of buffer as a set of one second chunks.
The one second chucks at high bit rates, like HD.
Are obviously a larger number of bytes and use more room in the buffer and
are just shown as taller here.
The chunk at the head of the buffer is playing out to the screen and
a new chunk is downloading into the buffer.
The plot above the buffer is shown as a trap of the network's bandwidth.
Bandwidth is measured over a download of chunks.
If a chunk is two megabits and it took one second to download.
The bandwidth is measured as two megabits per second.
2:38
This measured bandwidth may be used as an estimate of the future network capacity.
If the estimated capacity is less than the video bit rate.
We need to request the next chunk at lower quality, our bit rate.
An easy way to think about this is if you're taking more than one second to
download the chunk that plays for one second.
Then you need to view the video at lower quality if you want to prevent
rebuffering.
3:12
This technique is called adaptive betrayed streaming.
One cool thing to is that all the logic for
the bit reader adaptation resides on the client side.
So the CD and server side can actually be quite simple.
3:25
This works reasonably well and
at least until recently some variant of this was Netflix's default approach.
But there is room for improvement.
The problem is that capacity estimation is hard to get right.
If your estimate is too conservative,
you're unnecessarily viewing the stream at lower quality, which is undesirable.
If your estimate is too aggressive, you request higher quality chunks.
And the buffer drains out because of the time it takes to get those chunks and
this causes the video to pause.
This pause is called a rebuffer.
We refer to this term rebuffer, or
rebuffering often in the following discussion.
The difficulty of estimating network capacity is reflected in this plot.
It shows for one Netflix video player's trace, the average throughput
over chunk downloads, that's on the y-axis, over time on the x-axis.
Notice how the average throughput varies in a wide range.
10% of sessions in a random sample of 300,000
Netflix sessions Show high variability in network capacity.
This variability means that the capacity estimation is often off the mark.
20 to 30% of all rebuffers seen in this data set were found to be avoidable.
That is,
switching to a lower quality video stream would have avoided the need to pause.
Of course, if the network's capacity is lower than the lowest video bitrate.
Then there's no avoiding rebuffering.
You will see frequent rebuffering in that case.
5:04
The key idea of this work is this.
It's the buffer's occupancy that we care most about.
Can we make decisions based on the buffer occupancy alone?
The answer is, for the most part.
6:04
It's not necessarily linear, though.
That's just the example here.
We will omit details of the function explored in this paper.
But nevertheless, one problem remains.
What about the startup phase?
6:24
A simple form of capacity estimation is indeed useful in this startup phase.
Note that reality is a bit more complex than what we discussed here.
For example, video encoding rates Aren't continuous but rather discreet.
So you might have just a few options between the lowest bit rate and
the highest HD bit rate.
So you need to figure out how discretize the rate function.
The paper does address these issues in case you're interested.
How well does this approach work?
The paper includes real world results from a massive experiment.
The data was gathered over 500,000 users of Netflix
browser based player, over a weekend in September 2013.
Each group in their ab tests played roughly 120,000 hours of video.
Let's look at the two primary quantities of interest,
the number of free buffers and the video quality.
7:17
The x-axis of this plot is time in GMT.
The yellow bands represent peak Netflix hours in the US.
The y-axis is the number of free buffers
normalized to the number of free buffers in the control algorithm.
So the control algorithm is what this work is comparing against.
And that's Netflix capacity estimation based approach,
in deployment at the time of these experiments.
7:54
From the lower bound result we can gather that there's roughly 20 to 30% room for
improvement in the best case.
The buffer adaptation algorithm marked BBA achieves performance quite
similar to the lower bound, especially in the peak hours.
It achieves 10 to 20% fewer rebuffers than the control algorithm.
Further, the buffer-based algorithm,
unlike the lower bound in this scenario, does not compromise on video quality.
This is what the other result we'll discuss shows.
8:38
Lastly, it's useful to remind ourselves that this algorithm
is deployed in the browser-based layer on top of standard protocols.
In such applications where there is enough value.
There's a strong argument for the application to take on some of the tasks
that the general purpose network isn't necessarily adept at.
[MUSIC]
P. Brighten GodfreyAssociate Professor
Ankit SinglaAssistant Professor
