从非常高的层面来看，客户端（浏览器，移动应用等）从服务器请求视频。
由于视频很大，用户不希望等待整个视频下载后才能播放，大多数客户端都设计为在客户端有足够的视频时立即开始播放视频能够解码并开始播放。
大多数客户端和服务器，现在至少是HTTP支持流：
- 客户端接收有关视频在内的总文件大小（如75000个字节）的信息。
- 客户端最初请求视频子集 - 例如字节0 - 5000.
- 客户端接收，解码并开始播放接收到的初始字节。随着播放的进行，客户端请求视频的下一部分 - 例如，字节5001-10,000等等。
自适应比特率流建立在此，以满足不同的网络条件：
- 服务器包含同一视频的多个副本，在不同的比特率编码，允许不同的网络速度（较高位作为一般规则，质量更好）。这些视频都被分解成相同的长度（从时间的角度来看）块 - 例如， 2秒的块。
- 客户端请求有关视频的信息（例如使用网页中的源URL），并接收“索引”或“清单”文件作为响应。此文件包含指向此视频的所有视频，音频，字幕流等的指针
- 客户端从清单中列出的某个比特率流中请求第一个视频块。例如，它可能从一开始就以最低比特率开始，以确保视频快速启动并在出现网络问题的情况下。
- 如果第一个块下载成功，那么客户端将请求一个块，形成下一个2秒视频的下一个最高比特率。
- 客户端重复此操作直至达到最高比特率，或者看到下载块的延迟，这意味着对于当前网络条件，此比特率过高。
- 客户端在整个回放期间继续监视连接，并根据网络条件升高或降低比特率。
实际上，你可以看到在YouTube上，Netflix公司等的ABR效果：当你开始一个视频，你会经常看到，因为它的步骤了比特率的质量不如第一30秒到一分钟。
YouTube还有一些很好的统计数据，您可以通过右键点击视频并查看“书呆子统计数据”来访问。