流媒体简介

直播协议

RTP/UDP:可以做到秒内延时，目前国内的CDN都不支持，但有些公司开发了私有协议实现了基于它们的直播，而且它们的延时都小于1秒，甚至小于500ms,像YY，映客直播采用的第三方技术等。
webRTC: 可以做到秒内延时，实际上它也是使用的RTP，单列出来是因为它是Google开源出来的，目前社区也开始活跃，做的人也多了；依据它出服务的公司国内有声网，中国电信研究院等。
HTTP-FLV: 内容延迟可以做到2~5秒，打开快。
RTMP: 内容延迟可以做2~5秒，当网络不好造成重传时，延时会大量增加。
HTML5 WebSocket: 方案还不成熟，延时可能也会在2~5秒。
HLS:  有5~7秒的内容延迟。

点播

点播视频的格式有挺多种，如：FLV、MP4、AVI、MKV、RM、 等等都是指视频的封装格式。

视频文件都会包含一个 metadata 的数据块，记录了当前文件的图像尺寸、编码格式、帧率、码率等信息。播放器在网络点播场景下去请求视频数据，需要先获取到文件的 metadata 信息，解析出该文件的编码、帧率等信息后才能实现边下载数据，边送给解码器进行解码，最后通过渲染层将解码后的数据播放出来。

基础知识：I帧、B帧、P帧

I帧表示关键帧。可以理解为这一帧画面的完整保留；解码时只需要本帧数据就可以完成，因为包含完整画面。
P帧表示这一帧跟之前的一个关键帧（或P帧）的差别。解码时需要用之前缓存的画面叠加上本帧定义的差别，生成最终画面。也就是差别帧，P帧没有完整画面数据，只有与前一帧的画面差别的数据。
B帧是双向差别帧。B帧记录的是本帧与前后帧的差别（具体比较复杂，有4种情况）。换言之，要解码B帧，不仅要取得之前的缓存画面，还要解码之后的画面，通过前后画面的与本帧数据的叠加取得最终的画面。B帧压缩率高，但是编解码时会比较耗费CPU，而且在直播中可能会增加直播延时，因此在移动端上一般不使用B帧。

DTS（Decoding Time Stamp）：即解码时间戳，告诉播放器该在什么时候解码这一帧的数据（解码用）
PTS（Presentation Time Stamp）：即显示时间戳，告诉播放器该在什么时候显示这一帧的数据（播放用）

比如一个视频中，帧的显示顺序是：I B B P，现在我们需要在解码 B 帧时知道 P 帧和 I 帧中信息，因此这几帧在视频流中的顺序可能是：I P B B。DTS 告诉我们该按什么顺序解码这几帧图像，PTS 告诉我们该按什么顺序显示这几帧图像。顺序大概如下：

   PTS: 1 4 2 3
   DTS: 1 2 3 4
Stream: I P B B

延迟与卡顿的取舍

需要更低的延时，则表明服务器端和播放端的缓冲区都必须更短，来自网络的异常抖动容易引起卡顿。

业务可以接受较高的延时时，服务端和播放端都可以有较长的缓冲区，以应对来自网络的抖动，提供更流畅的直播体验。

优化

这里通常有两种技术来平衡和优化这两个指标。

一是服务端提供灵活的配置策略，对于延时要求更敏感的，则在服务端在保证关键帧的情况下，对每个连接维持一个较小的缓冲队列；对于卡顿要求更高的直播，则适当增加缓冲队列的长度，保证播放的流畅。

二是服务端对所有连接的网络情况进行智能检测，当网络状况良好时，服务端会缩小该连接的缓冲队列的大小，降低延迟；而当网络状况较差时，特别是检测到抖动较为明显时，服务端对该连接增加缓冲队列长度，优先保证播放的流畅性。

 

网络部分的优化是两点
1. 使用自己的HTTPDNS，换句话说，就是要搭建自己的快速高并发的调度系统；
2. 使用BGP机房；