流媒体点播/直播服务架构设计，类HLS协议

有一个关于通信网络的冷笑话：

2G时代，你可以看苍井空.txt

3G时代，你可以看苍井空.jpg

4G时代，你可以看苍井空.avi

于是可以看到，如今的网络时代已经进入了流媒体时代，了解如何搭建一个流媒体服务器，是十分有意义的。最近，我们简单实现了一个流媒体点播&直播服务，采用了类似HLS协议的方法，给大家分享一下。

什么是HLS？

关于HLS介绍的文章，随便搜一下就可以搜到一大堆，这里就简单介绍一下。（WIKI）

HLS的全称是Http Live Streaming，是由苹果公司提出的一套基于HTTP传输流媒体的网络协议。它的工作原理是把一个大的视频文件切分成不同的小文件，一般来说每个小文件是10s左右。然后用户播放的时候，按照顺序依次下载每个小视频即可，下载一个播一个，只要网络稳定带宽足够，便可以流畅的播放完整个视频。但这种方法有一个坏处，在最开始播放和跳转到某个点播放时，会有一定的延迟，因为毕竟要等那个点的第一个文件下载完成才能播。如果加密了视频的话，还需要播放时解密，也会产生一定的延迟。

我们的类HLS协议

一开始我们想直接使用HLS协议，毕竟是标准协议。但遇到了一个问题，ts采用的是MPEG2的视频格式，相同清晰度下，比一般用的H.264视频格式大了一倍。虽然网络越来越快了，但生活在天朝，网络还是不确定的，所以减少视频文件的体积非常重要。最后我们决定不使用ts，而使用H.264+AAC封装的flv，对Flash播放器十分友好。与此同时，还需要生成flv的列表文件，类似于ts的m3u8文件。

除了视频格式上的差异之外，其它地方均和HLS协议一致，也是采用HTTP渐进式下载，也是采用AES-128-CBC加密，等等。（若需要加密，不推荐全文件加密，在Flash里的解密速度会比较慢）

样例视频：http://www.smartstudy.com/classroom-1059-30200.html

整体架构

 

 

如上图所示，这就是我们整个流媒体的架构设计，下面举例说明。

后端处理部分：用户A上传苍井空.avi这个视频后，首先经过我们的转码器处理（可以用ffmpeg实现），将视频拆分成若干个小切片和列表文件，例如苍井空.list、苍井空1.flv、苍井空2.flv、苍井空3.flv。之后对每个切片进行AES-128-CBC加密，秘钥存放到认证服务器上。最后将所有list和flv文件推送到CDN服务器上，至此后端处理完成。

前端处理部分：用户B想看苍井空.avi这个视频，首先向CDN服务器请求视频切片列表文件苍井空.list，同时向认证服务器请求解密的秘钥。之后根据列表文件，依次请求每个切片视频，也就是请求苍井空1.flv、苍井空2.flv、苍井空3.flv。最后拿到视频后在客户端进行解密，解密完后就是正常的视频流，可以调用相应的播放器播放。

其他细节

1）如果你们的服务对保密性要求不高的话，可以不对切片进行加密，可以省略掉流程中的很多步骤，同时节约客户端解密的时间。例如优酷的普通视频都是不加密的，可以直接下载下来看，但一些VIP电影之类的视频都是加密的，无法直接下载。以及，加密后在WEB端将无法使用HTML5的方式进行播放，暂时只能使用Flash。

2）在实际实现的过程中，最好对其中一些环节再进行一些细节处理，采用最适合实现需求的方式实现。

3）如果是非互动式的直播，可以采用这种方式实现，但如果有互动的，比如说有人可以随时提问，视频里的人要回答等等，不能够使用这种方式，因为会有几十秒的延迟，只能够采用RTMP的方式了。

4）在这种架构下，CDN的好坏是整个服务的关键，但搭建CDN的成本相对来说比较高。所以对于小公司来说，可以多用几家CDN进行对比，挑选出最适合你们的CDN。对于大公司的话，必须架设自己的CDN，或者部分架设自己的CDN，比如对于北上广深这些大城市走自己的CDN，其他二三线城市走第三方的CDN。

5）如果客户端莫名其妙出现丢包的现象，可以考虑检查宽带运营商的因素，有些运营商如果识别出数据包是视频的话，可能会被直接丢弃掉，因为这种视频数据包对它们来说最不值钱，在用网高峰期会优先照顾其它包。我们可以通过修改包格式，加密等方法搞定。