зеркало из https://github.com/GoogleChrome/kino.git
Review and update adpative streaming
This commit is contained in:
Родитель
867e5db767
Коммит
58ad5b5e64
|
@ -1,8 +1,10 @@
|
||||||
---
|
---
|
||||||
title: 'Adaptive Streaming'
|
title: Adaptive Streaming
|
||||||
description: 'Respond to changing network conditions by detecting the available bandwidth and inserting video chunks of appropriate bitrates.'
|
description: |
|
||||||
date: 4th March, 2017
|
Respond to changing network conditions by detecting the available bandwidth
|
||||||
length: '7:43'
|
and inserting video chunks of appropriate bitrates.
|
||||||
|
date: April 2nd, 2021
|
||||||
|
length: '1:04'
|
||||||
video-sources:
|
video-sources:
|
||||||
- src: https://storage.googleapis.com/wdm-assets/media/06/manifest.mpd
|
- src: https://storage.googleapis.com/wdm-assets/media/06/manifest.mpd
|
||||||
type: application/dash+xml
|
type: application/dash+xml
|
||||||
|
@ -21,31 +23,68 @@ video-subtitles:
|
||||||
srclang: cz
|
srclang: cz
|
||||||
thumbnail: https://storage.googleapis.com/wdm-assets/images/adaptive-bitrates.png
|
thumbnail: https://storage.googleapis.com/wdm-assets/images/adaptive-bitrates.png
|
||||||
---
|
---
|
||||||
### Introduction
|
|
||||||
|
|
||||||
One of the key benefits of video streaming is the ability to adapt to changing network conditions. Stream manifests usually expose multiple representations of the same video resource. When those representations differ in bitrate, the player can toggle between them seamlessly and always **load a chunk that fits** the currently available bandwidth.
|
## Introduction
|
||||||
|
|
||||||
|
Adaptive streaming is a technique where video chunks are encoded in various
|
||||||
|
bitrates to deliver the best possible experience **under all network
|
||||||
|
conditions**.
|
||||||
|
|
||||||
|
One of the key benefits of adaptive streaming is the ability to adapt to
|
||||||
|
changing network conditions. Stream manifests usually expose multiple
|
||||||
|
representations of the same video resource. When those representations differ
|
||||||
|
in bitrate, the player can toggle between them seamlessly and always **load a
|
||||||
|
chunk that fits** the currently available bandwidth.
|
||||||
|
|
||||||
|
Users may choose to start watching a video on their phone at home and then leave
|
||||||
|
their wi-fi and switch to a slower cellular network. The video player detects
|
||||||
|
the change in download speed and when it's about to request another chunk of
|
||||||
|
video, it can adapt to the new situation and download a lower bitrate chunk
|
||||||
|
instead.
|
||||||
|
|
||||||
|
The video at the top of the page will adapt to your available bandwidth. It logs
|
||||||
|
download speeds of media chunks being downloaded and computes a rolling average
|
||||||
|
of the data to determine the average real bandwidth between you and the media
|
||||||
|
server.
|
||||||
|
|
||||||
|
The application then chooses appropriate video representation with an average
|
||||||
|
bitrate that fits within the available bandwidth.
|
||||||
|
|
||||||
|
## Bitrate
|
||||||
|
|
||||||
|
Bitrate is a measurement of the amount of data per unit of time. For example,
|
||||||
|
a video with a bitrate of 500 kb/s will **on average** use 500 kilobits of data to
|
||||||
|
describe every second of content.
|
||||||
|
|
||||||
**Bitrate** is measure of amount of data per unit of time. For example a video with bitrate of 500 kbit/s on average uses 500 kilobits of data to describe every second of content.
|
|
||||||
### Constant bitrate
|
### Constant bitrate
|
||||||
|
|
||||||
Why *on average*? While it is possible to encode your videos with a **constant bitrate (CBR)**, consider what effects would a truly constant bitrate have on video quality.
|
Why **on average**? While it is possible to encode your videos with a **constant
|
||||||
|
bitrate (CBR)**, consider what effects a truly constant bitrate could have on
|
||||||
|
video quality.
|
||||||
|
|
||||||
Imagine a scene with a black text on white background. Encoder doesn't need much data to describe such scene even in great detail. Then imagine a subsequent scene with a confetti cannon firing. The scene is filled by small pieces of confetti of different colors. There is an extreme amount of data to be captured.
|
Imagine a scene with some black text on a white background. The encoder doesn't
|
||||||
|
need very much data to describe such a scene, even in great detail. Then
|
||||||
|
imagine a subsequent scene with a confetti cannon firing. The scene is filled
|
||||||
|
by possibly millions of small pieces of confetti of various colors. There is a
|
||||||
|
much higher amount of data captured in that second of video.
|
||||||
|
|
||||||
In the rendered file the first scene is going to be extremely crisp, while the second one blocky, smeared and full of compression artefacts.
|
In the rendered file the first second is going to be extremely crisp, while the
|
||||||
|
second one blocky, smeared and full of compression artefacts.
|
||||||
|
|
||||||
### Variable bitrate
|
### Variable bitrate
|
||||||
|
|
||||||
This is why **variable bitrate (VBR)** is generally considered a better fit for video encoding. Simple scenes are encoded using less data, complex scenes use more data. In this system encoders aim try to encode your media file in such a way that the final media file's average bitrate is as close to the supplied bitrate as possible.
|
This is why **variable bitrate (VBR)** is generally considered a better fit for
|
||||||
|
video encoding. Simple scenes are encoded using less data, while complex scenes
|
||||||
|
use more data. In this system encoders aim to encode your media file in such a
|
||||||
|
way that the final media file's average bitrate is as close to the supplied
|
||||||
|
bitrate as possible.
|
||||||
|
|
||||||
### Adaptive streaming
|
## What's Next?
|
||||||
|
|
||||||
Adaptive streaming uses video chunks encoded at different target bitrates to deliver the best possible experience **under all network conditions**.
|
We hoped you have enjoyed learning about the techniques used to encode and play
|
||||||
|
video on the web. Check back from time to time as we will be expanding on this
|
||||||
|
PWA and building more features and writing new content. If you want to contribute
|
||||||
|
to the code that runs this site, make a suggestion, request a feature, or just
|
||||||
|
want to see how it was built go check out the [source code].
|
||||||
|
|
||||||
User may choose to start watching a video on their phone at home and then leave their wi-fi and switch to a slower cellular network. The video player detects the change in downlink speed and when it's about to request another chunk of video, it can adapt to the new situation and download a lower bitrate chunk instead.
|
[source code]: https://github.com/xwp/web-dev-media/
|
||||||
|
|
||||||
### Example
|
|
||||||
|
|
||||||
The video at the top of the page will adapt to your available bandwidth. It logs download speeds of media chunks being downloaded and computes a rolling average of the data to determine the average real bandwidth between you and the media server.
|
|
||||||
|
|
||||||
The player application then chooses appropriate video representation with an average bitrate that fits within the available bandwidth.
|
|
||||||
|
|
Загрузка…
Ссылка в новой задаче