最近直播比较火，那一个直播系统里有哪些组成部分，都用了哪些协议呢？
无论直播还是点播，都是对于视频数据的传输。这里面涉及到许多的技术名词。
视频是什么？其实视频是快速播放的一连串连续的图片。
每一张图片，称为一帧。只要图片播放的速度足够快，比如每秒30帧以上，我们就会看到一个动起来的视频。每秒钟的帧数称为帧率。
每一张图片都是由像素组成的，假设1024*768（这是很低的分辨率），每个像素由RGB组成，每个8位，共24位。
那每秒钟的视频有多大？
30帧×1024×768×24=566,231,040Bits=70,778,880Bytes
如果一分钟呢？4,246,732,800Bytes，大约4G。
可以看到这个数据量很大，非常耗费带宽和硬盘空间。
于是，人们想到了编码，就是看如何用尽量少的空间保存视频，同时不影响视频的观看质量。编码就是一个压缩的过程。
视频和图片有这样一些特点。
编码的算法非常多，但是编码的过程都很类似。
视频编码的两大流派，即两大标准。
后来，ITU-T（国际电信联盟电信标准化部门）于MPEG联合制定了H.264/MPEG-4 AVC，这才是我们这一讲重点关注的。
经过编码，一帧帧的图像，就变成了一串串看不懂的二进制，这个二进制可以放在一个文件里，按照一定的格式保存起来，这就是名词系列一。
这些视频保存成文件的格式，例如，前几个字节代表什么意思，后几个字节代表什么意思，然后是数据，数据中保存编码好的结果。
编码之后的二进制可以通过网络协议进行封装，放在互联网上传输，这个时候就可以进行网络直播了。
网络协议将编码好的视频流，从主播推送到服务器，在服务器上有个运行同样协议的服务端来接收这些网络包，从而得到里面的视频流，这个过程称为接流。
服务端接到视频流之后，可以对视频进行一定的处理，例如转码，从一个编码格式转成另一种格式。因为观众的客户端千差万别，要保证他们都能看到直播。
流处理完毕后之后，就可以等待观众的客户端来请求这些视频流，观众的客户端请求过程称为拉流。
如果观众非常多，看同一个视频，都从一个服务器上拉流，压力太大，需要一个视频的分发网络，将视频预先加载到就近的边缘节点，这样观众看的视频，是从边缘节点拉取的，就能降低服务器的压力。
当观众的客户端将视频流拉下来之后，就需要进行解码，即编码的逆过程。将一串串看不懂的二进制转变成一帧帧的图片，通过客户端播放出来，就能看到美女帅哥了。
整个直播过程，用下面的图描述。
我看下每个过程。
视频是一张张图片的序列，如果每张图片都完整传输，就太大了，因而将视频序列分成三种帧。
可以看出，I帧最完整，B帧压缩率最高，而压缩后帧的序列，应该是以IBBP的间隔出现的。这就是通过时序进行编码。
在一帧中，分成多个片，每个片分成多个宏块，每个宏块分成多个子块，这样将一张大图分解成一个个小块，方便空间上的编码。
最终要压缩成一个二进制流。这个流是有结构的，是一个个的网络提取单元（NALU，Network Abstration Layer Unit）。变成这种格式是为了传输，因为网络上的传输，默认的是一个个的包，因而这里就分成了一个个单元。
每一个NALU首先是一个起始标识符，用于标识NALU之间的间隔；然后是NALU的头，里面配置了NALU的类型；最终Payload里面是NALU承载的数据。
在NALU头里面，主要的内容是类型NALU Type。
在传输视频流之前，必须传输这两类参数，不然无法解码。为了保证容错性，每个I帧前面都会传一遍这两个参数集合。
如果NALU Header里面的表示类型是SPS或PPS，则Payload中就是真正的参数集的内容。
如果类型是帧，则Payload中才是真正的视频数据。
这样，整个格式就有了。一个视频，可以拆分成一系列的帧，每一帧拆分成一系列的片，每一片都放在一个NALU里面，NALU之间通过特殊的起始标识符分隔，在每一个I帧的第一片前面，要插入单独保存的SPS和PPS的NALU，最终形成一个长长的NALU序列。
这个格式是不能直接传输到对端的，还需要将这个二进制的流打包成网络包进行发送，这里我们使用RTMP协议。这就进入第二个过程，推流。
RTMP是基于TCP的，所以需要双方建立一个TCP连接，在TCP连接的基础上，还需要建立一个RTMP连接，即在程序里，调用RTMP类库的Connect函数，显示创建了一个连接。
RTMP为什么要创建单独的连接呢？
因为它们需要商量一些事情，保证以后的传输能正常运行。主要是两个事情，一个是版本号，如果客户端和服务端的版本号不一致，就不能正常工作。另一个是时间戳，视频播放中时间是很重要的，因为一开始要知道对方的时间戳。
沟通这些事情需要发送六条消息：客户端发送C0、C1、C2，服务端发送S0、S1、S2.
首先，客户端发送C0表示自己的版本号，不必等待对方的回复，然后发送C1表示自己的时间戳。
服务器收到C0 的时候，返回S0，表明自己的版本号，如果版本号不匹配，可以断开连接。
服务器发送完S0后，也不用等什么，就直接发送自己的时间戳S1。客户端收到S1后，发送一个直到了对方时间戳的ACK S2。同理，服务器收到C1的时候，发送一个直到了对方时间戳的ACK S2。
于是，握手完成。
握手之后，双方需要相互传递一些控制信息，例如Chunk块的大小、窗口大小等。
真正传输数据的时候，还是需要创建一个流Stream，然后通过这个Stream来推流publish。
推流的过程，就是将NALU放在Message里面发送，这个也称为RTMP Packet包。Message 的格式就像这样。
发送的时候去掉NALU的起始标识符。接下来，将SPS和PPS参数集封装成一个RTMP包发送，然后发送一个个片的NALU。
RTMP在收发数据的时候也不是以Message为单位的，而是把Message拆分成Chunk发送，而且必须在一个Chunk发送完之后，开始下一个Chunk。每个Chunk都带有Message ID，表示属于哪个Message，接收端按照这个ID将Chunk组装成Message。
前面建立的时候，设置的Chunk块大小就是指这个Chunk。将大消息变成小块再发送，可以在低带宽的情况下，减少网路拥塞。
这有一个分块的例子。
假设一个视频的消息长度为307，但是Chunk大小约定为128，于是拆分成三个Chunk。
第一个Chunk的Type=0，表示Chunk头是完整的；头里面Timestamp为1000，总长度Length为307，类型为9，是视频，Stream
ID为12346，正文部分承担128个字节的Data。
第二个Chunk也要发送128个字节，Chunk头由于和抵押给Chunk一样，因此采用Chunk Type=3，表示头一样，不再重复发送了。
第三个Chunk要发送的Data长度为307-128-128=51个字节，还是采用Type=3。
这样数据就不断到达流媒体服务器，整个过程像这样。
这个时候，大量看直播的观众就可以通过RTMP协议从流媒体服务器上拉取，但是这么多用户从一个地方拉取，服务器压力会很大，而且用户分布在世界各地，如果统一去一个地方下载，会很耗时，需要有分发网络。
分发网络分为中心和编译两层。边缘服务器部署在各地，利用户很近。中心曾是流媒体服务集群，负责内容的转发。智能负载均衡系统，根据用户的地理位置信息，就近选择边缘服务器，为用户提供推/拉流服务。中心曾也负责转码服务。例如，把RTMP协议的码流转换为HLS码流。
先读到的是H.264的解码参数，例如SPS和PPS，然后对收到的NALU组成的一个个帧，进行解码，交给播放器播放，视频画面就出来了。
两个思考题：
1. 你觉得基于RTMP的视频流传输的机制存在什么问题？如何进行优化?
2. 在线看视频之前，大家都是把电影下载下来看，电影这么大，你知道如何快速下载码？
