播放器技术-DASH协议开发
播放器技术-DASH协议（直播）
播放器技术-DASH协议开发（DASH特点）
播放器技术-DASH协议开发
播放器技术-DASH协议开发（背景）
播放器技术-DASH协议开发（协议差异）
协议 | 传输方式 | 视频封装格式 | 编码 | 数据分段 | 延时 | 成本 | 自适应 | 标准 |
FLV | http | flv | H264等，AAC等 | 连续流 | 低 | 低 | 不支持 | Adobe |
RTC | udp | xxx | xxx | 连续流 | 低 | 高 | 支持 | 私有协议 |
HLS | http | ts文件 | H264,AAC | 切片 | 高 | 较低 | 支持 | Apple |
MPEG-DASH | http | mp4、3gp、webm等 | H264等 AAC等 | 切片 | 高 | 低 | 支持 | 国际标准 |
播放器技术-DASH协议开发（目前阶段性成果）
- Dash功能已经灰度
- 性能测试组测试报告中
- CPU、内存基本和flv持平
- 弱网情况下Dash表现要优于flv
- 由于协议差异，Dash相比flv时延要高一些（flv 4.6-6s，dash 6-8s）
播放器技术-DASH协议开发（阶段性成果）
播放器技术-DASH协议开发
播放器技术-DASH协议开发（播放器结构图）
播放器技术-DASH协议开发（描述文件MPD）
播放器技术-DASH协议开发（数据格式）
播放器技术-DASH协议开发（DashDemuxer架构图）
播放器技术-DASH协议开发
- 首帧优化
- 时延控制
- 刷新mpd策略
- 音视频块同步
- 自适应切换
- 线程模型优化
- 内存优化
- 解决Dash技术性问题
播放器技术-DASH协议开发（首帧优化）
首帧的耗时
-建立连接到Response 200耗时
-Response 200到解封装第一个关键帧耗时
-DASH包含了mpd解析、init块下载，首个数据段能够解析出第一帧
-首帧推送解码，到解码完成耗时
播放器技术-DASH协议开发（首帧优化）
- 边下载边解复用
- 音视频并发下载，视频优先
- 加入DASH预加载（mpd，init块，第一个数据segment）
- 网络
- QUIC
- GSLB支持腾讯云域名
- DNS域名预解析
播放器技术-DASH协议开发（时延控制）
播放器时延控制模式
- 正常模式
- 选取当前集合中的倒数第二个
-低时延模式
- 始终以当前集合的最后一个为数据下载段
播放器技术-DASH协议开发（刷新MPD策略）
播放器时延控制模式
- 正常模式
- 选取当前集合中的倒数第二个
-低时延模式
- 始终以当前集合的最后一个为数据下载段
complete
新的数据块
Refresh
complete
无数据块更新，则200ms后再次发起数据更新，直到更新到数据
间隔2s（mpd）
Refresh
Refresh
播放器技术-DASH协议开发（音视频块控制）
音频和视频块
- 音频块、视频块是对齐的，同一个时间段内，有一个音频和视频
- 需要正常播放的前提是同时需要音视频块
- 音频块相比视频块要小的多，如果不加控制，可能视频块下载时间过长，而音频块下载过多，从而导致卡顿
控制逻辑
- 为每个Segment分配一下自增的id
- 音视频各自下载单元进行序号的同步，只有相同的id下载结束后才进入下载下一个片段
播放器技术-DASH协议开发（自适应切换）
主要规则：
ThroughputRule InsufficientBufferRule
测速模块-ThroughputRule
-使用滑动窗口平均估计未来吞吐量，选择不高于估计值的最大码率视频
-窗口大小为4~20（抖动越剧烈，计算窗口越大 ），并对平均后的吞吐量×0.7作为估计值
播放器技术-DASH协议开发（线程模型优化）
-线程模型优化
- 解码和下载都会创建独立的线程，增加资源的消耗
- 优化成post task模型
播放器技术-DASH协议开发（解决Dash技术问题）
播放器技术-DASH协议开发（音画同步卡顿问题）
播放器技术-DASH协议开发（音画同步卡顿解决方案）