This site is only a doorway

Everything here is gathered from things other people actually researched, thought through, and built: books, papers, historical records, and the people behind them. If something here catches your interest, go look at the original sources listed at the bottom of the page. They carry more depth than a page like this ever can.

Why Does Video Quality Change While You Are Watching?

Category: Technology

You are watching a video and the picture suddenly goes soft. A few seconds later it is sharp again. Nobody pressed a button. The short answer is that the player on your own phone, tablet, or TV chose a different version of the video, and it can only do that at the seams between short chunks of a few seconds each. [2] [3]

What does the player look at when it chooses? You might guess "how fast the internet is right now." A large Netflix experiment suggests that how much video the player has already saved up is a better guide. This page follows that idea, and then looks at why some scenes look rough even when the quality setting never changes. [4]

1. Who Decides to Change the Picture Quality of a Streaming Video?

YouTube's help page says it changes the quality of your stream based on your viewing conditions, and that this is why quality can change as you watch. The factors it lists include the speed of your internet connection, the size of the screen, and the quality of the original upload. [1]

Behind this is a simple trick. The same video is prepared in several versions, from low quality to high quality. The HLS streaming standard calls them "variant streams." Each version is cut into short pieces, often a few seconds long. The standard calls a target length of 10 seconds "typical," though real services can use shorter ones. [2] [3]

The player keeps a list of the versions and the pieces. Before it fetches each piece, it can pick which version to ask for. The standard requires matching content in the versions to carry matching timestamps, so the player can switch between them smoothly. [2] [3]

It is a bit like a cafeteria where the same meal is offered in small, medium, and large trays, and you may change your mind every time you go back to the counter. The standard says players should switch to match network conditions, but it does not say how to calculate the switch. That part is left to each service. [2]

2. Why Is It Hard to Choose a Quality Level by Measuring Internet Speed?

The obvious plan is to measure the connection speed and pick the best version that fits. In a 2014 paper by researchers at Stanford University and Netflix, each video was stored at several rates, typically from 235 kilobits per second for standard definition up to 5 megabits per second for high definition. That is a spread of roughly twenty times. These were the numbers for Netflix at that time, not for today. [4]

The authors say that estimating the available capacity is "fraught with difficulties." Several control systems inside the network and the server interact, so the speed you measure for one piece may not match the speed you get for the next. [4]

A wrong guess fails in one of two ways. If the player picks a version that is too big for the real speed, the saved-up video drains away and playback freezes. That freeze is called a rebuffer, and it is the spinning wheel most people dislike. If the player plays it safe and always picks the smallest version, it rarely freezes, but the picture stays soft. [4]

So the player is caught between "never stop" and "look good," and a shaky speed guess makes that harder. The researchers asked whether something else could guide the choice. [4]

3. Why Does Watching the Saved-Up Video Reduce Freezing?

A streaming player downloads a little video ahead of what you are watching and keeps it in a small store called the buffer. The buffer is something the player knows exactly, because it can simply look at how many seconds are stored. [4]

The paper's idea was to use the buffer as the main signal. When the buffer is nearly empty, pick the lowest quality. As the buffer fills, step up to better quality gradually. The authors say their method does away with estimating network capacity and instead focuses on the amount of video in the buffer. [4]

They built it into the Netflix video player and tested it with millions of Netflix users around the world. Compared with Netflix's own method at the time, the paper's abstract says it cut the rate of rebuffering by 20% while holding the video rate constant. That 20% is a comparison with one service's method of that era, not a promise for every service or every connection. [4]

There is one more detail. The method keeps a cushion at the bottom: while the buffer is below a certain amount, it sticks to the lowest quality. As summarised in the Japanese edition of this site, the reason is that the connection can suddenly slow down while a big piece is downloading, and the buffer could run dry before the player has time to react. In the paper's experiments each piece was 4 seconds long. [4]

This also hints at why videos often start soft. At the very beginning the buffer is empty, so there is nothing saved up to judge by. The paper notes that early on, a simple estimate from recent download speed is still useful. It is reasonable to think that this is one reason the first seconds are often lower quality, though the paper does not describe any particular app. [4]

4. Why Is a Quality Level Not the Same Size Every Time?

A quality level is labeled with a number, such as 5 megabits per second. That number is an average. Most streamed video is made with variable bitrate, so the real amount of data wobbles above and below the label from one piece to the next. [4]

As a rough example, 5 megabits per second for a 4-second piece averages about 2.5 megabytes of video data. Individual pieces can be smaller or larger than that. [4]

Why would some pieces be bigger? Video compression often stores only what changed since a nearby picture, because the parts that stay the same do not need to be sent again. Amazon's engineering blog explains this with P-frames and B-frames, which record differences from earlier or surrounding pictures. [7] From that idea, it is reasonable to expect that a scene with a lot of motion has more differences to record and needs more data. This is an explanation from how the method works, and the sources do not measure it for every video. [7]

This is another reason the player wants a cushion. Staying on the same quality level can still mean pieces that take different amounts of time to download. [4]

5. Why Can Some Scenes Look Rough Even at the Same Quality Level?

This is a different puzzle from the first one. Even when the quality level does not change, a calm cartoon and a grainy, fast sports clip are, in general, not equally easy to squeeze into the same number of bits. [6]

For years a service might use one fixed "ladder" of quality levels for every title. Netflix described a change to give each title its own ladder, tailored to how complex that title is. The quote usually cited is that each title "should receive a unique bitrate ladder." We could not open Netflix's own post for this page, so this part rests on an analysis article that quotes it and was published in January 2016. [5]

Fora Soft's explainer gives the everyday picture. A cartoon does not need 6 megabits per second, while a grainy sports clip shows blocky patches at the same 6 megabits per second. Flat colors, clear edges, and little motion are easy to compress. Film grain, fast movement, and crowds are hard. [6]

So there are two different reasons the picture can look worse, and they are easy to mix up. One is that the player moved to a lower rung of the ladder because of the buffer and the connection. The other is that the scene itself is hard to compress at the current rung. [4] [6]

6. How Can You Notice Which Kind of Quality Change You Are Seeing?

Next time you watch something, pick a spot on the screen and see when the picture changes. Ask yourself two questions. Did the picture go soft near the start, or in the middle? And is there a scene that looks rough even though the picture did not seem to change overall: a quiet conversation, or a chase with lots of motion? [4] [6]

These are predictions from the ideas above, not guarantees. Many things can differ between services, devices, and connections. Notes on when and what kind of scene may help you compare with the sources later. Take breaks so your eyes do not get tired, and ask whoever owns the device before changing settings.

To dig deeper, the HLS standard [2] and the MDN guide [3] show how the pieces and versions are organised, and the Stanford and Netflix paper [4] explains the buffer idea with experiments. How YouTube and other services decide inside their own players is not described in the public sources we read, so that is a good open question.

Sources

Reading status: the YouTube Help page, the arXiv abstract and full paper PDF, the RFC 8216 information page, the MDN page, and the two explainer articles were opened and read in part (long documents were read only as far as the fetch tool returned). Netflix's own per-title post and the Amazon blog could not be opened for this page. The per-title part relies on explainer articles, and the P-frame and B-frame description relies on the Amazon blog as summarised in the Japanese edition of this site.

  1. YouTube Help, "Change the quality of your video" https://support.google.com/youtube/answer/91449?hl=en (Quality adjusts to viewing conditions; lists connection speed, screen size, and original upload quality.)
  2. RFC 8216, "HTTP Live Streaming" https://www.rfc-editor.org/rfc/rfc8216 (Variant streams, segment length, and switching; read only in part. This is an informational RFC, not an Internet Standards Track document.)
  3. MDN, "Setting up adaptive streaming media sources" https://developer.mozilla.org/en-US/docs/Web/Media/Guides/Audio_and_video_delivery/Setting_up_adaptive_streaming_media_sources (Several qualities split into chunks; no special server software needed.)
  4. Huang, Johari, McKeown, Trunnell, and Watson, "Using the Buffer to Avoid Rebuffers: Evidence from a Large Video Streaming Service" (arXiv:1401.2209, 2014) https://arxiv.org/abs/1401.2209 (Abstract and introduction read; the details of the buffer cushion, the 4-second pieces, and variable bitrate follow the Japanese edition and were not re-checked line by line.)
  5. Jan Ozer, "How Netflix Pioneered Per-Title Video Encoding Optimization," Streaming Learning Center (January 14, 2016) https://streaminglearningcenter.com/articles/how-netflix-pioneered-per-title-video-encoding-optimization.html (Secondary source quoting Netflix's per-title idea; opening portion read.)
  6. Fora Soft, "Per-Title & Per-Shot Encoding" https://www.forasoft.com/learn/video-quality/articles-vqm/per-title-and-per-shot-encoding (Company explainer, secondary source: cartoon versus grainy sports clip at the same bitrate.)
  7. AWS Japan blog, "Back to Basic: video compression mechanisms" https://aws.amazon.com/jp/blogs/news/jpmne-back-to-basic-what-mechanisms-are-used-behind-the-scenes-in-video-compression (Not opened for this page; P-frames and B-frames recording differences, taken from the Japanese edition. Secondary source, in Japanese.)