流媒体协议

新年快乐。

 

视频直播，现在是火爆级别应用，简单分析一下。

实际上视频就是快速播放图片，我自己也做过应用的slide切换效果，实际上就是通过编程来确定每个时间点应该在的位置，原则上允许各种误差，因为人眼看不出的基本。

 

假设一张图片1024*768。每个像素由RGB组成（每个8位，共24位），按30帧（很低了）来计算一秒的视频

30 帧 × 1024 × 768 × 24 = 566,231,040Bits = 70,778,880Bytes

可见非常大，我们怎么可能按这种来传播，哪有这么大带宽够用，所以我们就需要压缩：

　　空间冗余：图像的相邻像素之间有较强的相关性，一张图片相邻像素往往是渐变的，不是突变的， 没必要每个像素都完整地保存，可以隔几个保存一个，中间的用算法计算出来。

　　时间冗余：视频序列的相邻图像之间内容相似。一个视频中连续出现的图片也不是突变的，可以根 据已有的图片进行预测和推断。

　　视觉冗余：人的视觉系统对某些细节不敏感，因此不会每一个细节都注意到，可以允许丢失一些数 据。

　　编码冗余：按照像素值的使用概率不同来决定字节的分配大小，霍夫曼编码。

 

 

 

视频直播有个关键的地方是，服务器是先分发，用户再拉流，避免服务器扛不住压力。

 

编码：如何将图片变为二进制流？

将每个图片分为三个帧保存

I 帧，也称关键帧。里面是完整的图片，只需要本帧数据，就可以完成解码。

P 帧，前向预测编码帧。P 帧表示的是这一帧跟之前的一个关键帧（或 P 帧）的差别，解码时需要用 之前缓存的画面，叠加上和本帧定义的差别，生成最终画面。

B 帧，双向预测内插编码帧。B 帧记录的是本帧与前后帧的差别。要解码 B 帧，不仅要取得之前的缓 存画面，还要解码之后的画面，通过前后画面的数据与本帧数据的叠加，取得最终的画面。

 

推流：如何将数据流推送到服务器

首先是将二进制打成网络包用RTMP协议传输，这里是先建立TCP连接，然后再建立一个RTMP连接，为什么还要多建立一次RTMP连接，这里主要是考虑到视频直播的特性，时间戳和版本号很重要。

 

因为它们需要商量一些事情，保证以后的传输能正常进行。主要就是两个事情，一个是版本号，如果客 户端、服务器的版本号不一致，则不能工作。另一个就是时间戳，视频播放中，时间是很重要的，后面 的数据流互通的时候，经常要带上时间戳的差值，因而一开始双方就要知道对方的时间戳。 

 

 

还需要沟通的是窗口大小啊，带宽等

 

 

分发网络

分发网络分为中心和边缘两层。边缘层服务器部署在全国各地及横跨各大运营商里，和用户距离很近。 中心层是流媒体服务集群，负责内容的转发。智能负载均衡系统，根据用户的地理位置信息，就近选择 边缘服务器，为用户提供推 / 拉流服务。中心层也负责转码服务，例如，把 RTMP 协议的码流转换为 HLS 码流。

 

 

 

 拉流：观众咋看?

这里其实和推流差不多

 

 

实际上来看，即使目前做了种种优化，视频还是十分重量级的费带宽资源等的应用。

 

 

参考刘超《趣谈网络协议》