4.4.2 Coping With Network Performance: Video Streaming Adaptation in the Face of Variable Bandwidth

Loading...

来自 University of Illinois at Urbana-Champaign 的课程

Cloud Networking

180 个评分

浏览相关视频

您将在 Coursera 发现全球最优质的课程。以下是为我们为您提供的部分个性化建议

University of Illinois at Urbana-Champaign

Cloud Networking

180 个评分

课程 5（共 6 门，Specialization Cloud Computing）

In the cloud networking course, we will see what the network needs to do to enable cloud computing. We will explore current practice by talking to leading industry experts, as well as looking into interesting new research that might shape the cloud network’s future. This course will allow us to explore in-depth the challenges for cloud networking—how do we build a network infrastructure that provides the agility to deploy virtual networks on a shared infrastructure, that enables both efficient transfer of big data and low latency communication, and that enables applications to be federated across countries and continents? Examining how these objectives are met will set the stage for the rest of the course. This course places an emphasis on both operations and design rationale—i.e., how things work and why they were designed this way. We're excited to start the course with you and take a look inside what has become the critical communications infrastructure for many applications today.

从本节课中

Week 4

Zooming out from within data centers, this week will examine other pieces of the cloud networking ecosystem: inter-data center WAN connectivity, content distribution networks, end-user Internet connectivity, and application interactions with the network. We’ll learn what novel techniques in each of these areas are pushing the cloud’s capabilities farther.

4.1.1 Inter-Data Center Networking: The Problem11:31

4.1.2 Inter-Data Center Networking: Cutting-edge Solutions14:47

4.2.1 CDNs - Part 112:50

4.2.2 CDNs - Part 29:02

4.2.3 CDNs Discussion3:27

4.3.1 Client Connectivity15:54

4.3.2 Client Connectivity Discussion3:01

4.4.1 Coping With Network Performance: Application-layer Tweaks for Lower Latency17:25

4.4.2 Coping With Network Performance: Video Streaming Adaptation in the Face of Variable Bandwidth9:07

Interview - Bruce Maggs (2015)44:27

Interview - Roy Rapoport (2015)45:29

与讲师见面

P. Brighten Godfrey
Associate Professor
Department of Computer Science
Ankit Singla
Assistant Professor
Department of Computer Science, ETH Zürich

[MUSIC]

The last application layer technique we will discuss

is rate adaptation in video streaming.

The goal here is to provide the best video streaming experience in the face of

variable network bandwidth.

Obviously we'd like the highest possible video resolution.

So we'd prefer the picture on the right to the picture on the left.

But at the same time we'd like to avoid waiting for buffering.

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.

You're looking at the video buffer at the client device here.

We'll see how the video bit rate is supposed to vary

with the network's capacity.

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.

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.

And of course, if the capacity is higher than the video rate.

You may be able to jump to a higher quality video junk.

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.

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.

This paper from Stanford and Netflix researchers also proposes

a method of improving upon the capacity estimation-based approach.

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.

If the buffer is nearly full, we can use a larger bit rate, that is,

a higher video quality.

If the buffer is nearly empty.

We need to be using a lower bit rate.

That is, lower video quality, if you want to avoid rebuffering.

This intuition can be captured formally as a function

that map buffer occupancy to the next video chunk's bit rate.

If the buffer occupancy is high, we can use the highest video quality.

If it's low, we must request lowest video quality for the next chunk.

This ensures that as long as the network's capacity exceeds

the lowest video bit rate.

The video stream will not suffer from a rebuffer.

Between these extremes,

the junk rate is a non decreasing function of buffer occupancy.

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?

When the stream has just started,

the buffer occupancy gives us very little information.

How do we make decisions then?

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.

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.

The lower bound curve shows the best possible result for rebuffers.

That is if the video were played at the lowest quality throughout.

What would the number of rebuffers be?

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.

Here the y axis is the video rate difference between the default

control algorithm and BBA.

BBA achieves higher video rate throughout.

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]

探索我们的目录

免费加入并获得个性化推荐、更新和优惠。

Coursera 致力于普及全世界最好的教育，它与全球一流大学和机构合作提供在线课程。

© 2019 Coursera Inc. 保留所有权利。

通过 App Store 下载

通过 Google Play 获取