1. 论文对比

2014年: 基于buffer

BBA

基本单位chunk 4s

解决的问题：

通过2个buffer阈值，构建一个buffer的函数，将buffer保持在一个合理的范围内，只有在启动阶段才使用throughput作为辅助，其他时刻只是用buffer

核心问题：吞吐量预测不准，buffer调整太过于保守

QoE：卡顿，码率

协议：DASH

BBA-0：线性模型

BBA-1：非线性模型

BBA-2：快启动+非线性模型

BBA-other：快启动+非线性模型+平滑切换

2015年：基于quality

MPC

基本单位chunk:4s

优势：对未来的关键环境进行预测与优化，可解释性，参数更新容易问题是在线很难实现，需要离线训练，在线测试，并且通过FASTMPC只能过去近似最优解

 

QoE：卡顿，码率,平滑

协议：DASH

提出挑战，解决挑战

2017年:基于RL

pensieve

基本单位chunk：4s

解决的问题：

1. 网络吞吐量的变化

 2. QoE

3. 码率选择的连串反应

4. 码率选择的调优

 

QoE：卡顿，码率,平滑 协议：DASH

2. 直播传输协议：

httpflv, rtmp协议

目前绝大多数公司更多的是在TCP或者UDP的基础上封装一个传输协议，适应本系统的私有协议。

Httpflv：

传输http流,视频封装格式是flv，延时低，数据不分段  Rtmp协议基础上开发的，适合直播

Rtmp：

传输tcp流，视频封装格式是flv，延迟低，数据不分段   Adobe公司开发  支持该协议的软件有Adobe/Uitrant/red5，适合直播

Hls：

传输http流，传输TS文件，延迟高，数据分段  苹果公司开发，适合点播和直播

dash：

传输http流，传输MP4文件，延迟高，数据分段，适合点播   适合点播

3. 直播过程：

采集--处理--编码和封装--推流到服务器--服务器流分发--播放器播放

主播--RTMP--直播流媒体服务器（CDN）--RTMP--关重

编码：

视频编码器：编码性能，编码速度，编码压缩比会直接影响流媒体的体验，编码种类有：H.265，VP8, VP9, H.264

音频编码器：MP3, AAC

封装：

不同的封装格式，例如：AVI, MPEG, WMV, FLV, MPEG2-TS, .flv, ,avi, .mpg, .dat, .mp4，.ts

 直播中主要采用的封装格式为：FLV, MPEG2-TS, 分别用于RTMP/HTTP-FLV和HLS流媒体传输协议，市面上绝大多数直播产品都采用的是RTMP协议

推流到服务器：

RTMP client和RTMP server，一个单一的连接可以通过不同的通道传输多路网络流，这些通道中的包都是按照固定大小进行包传输的。

流媒体服务器

负责流媒体的发布和转播分发功能

播放器播放

只要支持RTMP的播放器都可以

4. 直播未来的研究方向

  1. 基于规则的方式与基于增强学习的方式结合
  2. 对基于增强学习的方式进行改进：对reward进行改进，有chunk_reward改为迭代型的reward
  3. 分布式计算，分布式部署领域（边缘计算）
  4. 流量的异常检测
  5. 我们目前考虑的是CDN端到client端的情况，但是我们之后要考虑数据发送端到数据接受端的情况。
  6. 如果多用户和多用户通信，如何最优化目标码率
  7. CDN端对于非常火的视频资源可以转码多种码率，但是对于很早的视频，转码什么样的码率才是最合适的（依赖于客户的需求和需求客户的网络况状）
  8. 多源多目的之间的平衡
  9. 网络的吞吐量是不确定的，尤其是细粒度的吞吐量更不确定，但是buffer的占有情况是确定的，如何平衡网络吞吐量的预测结果与buffer的占有情况是一个挑战
  10. QoE目标中多个指标可能冲突。高码率，低卡顿，平滑切换，低延迟。更复杂的是，这些QoE的偏好不是定死的而是因用户而异
  11. 全局最优解。码率选择有级联效应。本次的码率选择，会影响下一次选择的buffer占用清空，会直接影响下一次的码率选择，进而影响整体的QoE。所以每一次的码率选择，也需要全局最优，而不是局部最优。buffer在为了实现全局最优，实际运作中会保持在一个安全范围内，使得码率更加保守。
  12. 预测的码率是一个连续值，如何进行合适的离散化，选择最优码率。就是预测的码率A比实际码率【B，C】之间，应该如何选择，选择不卡顿的低码率B，还是选择有卡顿几率的高码率。（这个前提就是网络吞吐量真的计算不准确）

5. 目前直播领域的问题

背景环境：

  • 目前工业界ABR的现状如何啊？近几年发展如何？
  • 目前直播的部署架构是怎么样的？
  • 目前直播的主流流媒体协议是什么啊？相对于点播，有没有专有的协议？
  • 直播的核心研究点是什么？
  • 真实环境和仿真环境区别有多大啊？

视频数据：

  • 每天给的视频数据是在一个CDN集群中找了其中的一个，真实的数据是啥样的啊？
  • 你们测试过一个东西吗？视频数据的帧大小，帧率与日期有关吗（例如：节假日与工作日）
  • 2个码率是真实情况吗？还是只是抽取了2个码率，其实真实情况为多个码率？

网络数据：

  • 比赛的网络数据是如何生成的？
  • 在真实环境中网络数据波动如何？有与时间波动规律吗？
  • 网络吞吐量的预测，目前公司做的如何？

6 .注意

目前的研究粒度一共可以划分为3种：基于GOP，基于chunk，基于frame

CBR encoding：固定码率编码（一次编码）。码率=实际的数据量/s

VBR encoding ：可变码率编码（二次编码），但是平均码率不变。在码率恒定的情况下，对内容简单的部分分配较少的比特，对内容较多的内容，分配较多的比特。这种编码方式使得同样的码率，但是chunk_size有不一样的大小，下载时间就不一样。码率=平均数据量/s

码率只是一个平均值，是指每秒平均的传输bit数

比赛采用的编码方式时VBR，所以码率是平均码率，重要的是chunk_size才是最有效，最直接的，最可控时延的信息

CDN中的1s视频在client的buffer中也是1s视频，只是下载这1s视频所需时间不一定是1s

CDN中有2s的视频，client的buffer中有5s的视频。

client将CDN中的1s视频下载到buffer中，需要花费3s。

此刻：CDN中有1s的视频，client的buffer中有5s-3s+1s=3s的视频

以帧为单位，最大的特点就是，卡顿时间会减少，延迟会减少，更加细粒度。 这样对网络吞吐量的预测要求更加严格，之前对于chunk，只需要预测chunk期间内的平均吞吐量，这是一个趋势指标，而不是一个时刻值，相对较容易。