文章目录

注：最近在找流媒体解决方案，顺便将过程遇到的东西梳理总结一下。

零、流媒体

0.1、流媒体本质

现实的图像，经过编码器压缩，持久化为点播文件或者直播流，经过传输，在终端解码和展示。

0.2、流媒体系统的层次

网络层(socket或st)负责传输；

协议层(rtmp或http)负责网络打包；

封装层(flv、ts、hls、hds、adts、annexb)负责编解码数据的封装；

编码层(h.264和aac)负责图像压缩。

流媒体服务器的重点在于封装层，譬如flv、ts、hls、hds、adts和annexb的解析和打包都是自己实现的代码，参考标准规范，支持完善的封装转换和解析。而网络层因为使用st简化，使得协议层更简单，错误的概率更低，这个和流媒体的关系就不大了。

0.3、目前开源的流媒体服务器

1、最古老的是RED5

RED5性能是很差

2、后面是CRTMPD

3、风生水起的是NGINX-RTMP

一、点播

1.1、概述

点播已经堕落为HTTP文件了，所以CDN支持点播支持得很得心应手。

1.2、技术

1、点播P2P，实际上分为客户端的P2P和web P2P

没有现成的方案，下面其他技术大多有成熟方案。

不过观止创想已经支持了点播HLS的P2P，现有系统不用修改就可以加上web P2P。

2、分片

3、DRM

4、弹幕

5、分享

6、多终端转封装

7、文件调度

8、HTTP API调度

9、热点

10、mp4/flv-range请求

11、存储

二、直播

2.1、概述

RTSP –> RTMP

HTTP渐进式下载 –> HTTP –> HLS和HDS –> DASH –> 私有的websocket

2.2、技术

WebRTC

Web Call Server 4

2.2、目前直播分发有几个特点

1、偏好flv，少用ts：

2、rtmp和hls并存；

3、实时流大多使用rtmp

4、rtsp永远死不了

2.3、技术选择

1、延迟要求，是否要求低于5秒的延迟?如果是硬指标，就只能选择RTMP或HTTP-FLV流。移动端需要自己编译FFMPEG支持，无法直接播放。

2、终端适配，是否要求支持PC和移动端(IOS和Android)?如果需要广泛支持移动端，HLS是最好的选择。

3、节约带宽，是否要求支持WebP2P?如果需要支持FlashP2P，或者移动端P2P，选择HLS。

三、协议转换

3.1、TCP与Websocket

1、参考师兄论文；

3.2、RTMP与websocket

1、在rtmp协议上面套一层websocket协议【2,3】

服务器端采用自己研发的rtmp服务器，为了方便在rtmp协议上面套一层websocket协议：

客户端js采用websocket与服务器连接，获取二进制流，解析rtmp协议，部分代码参考了Node-Media-Server；

解析H264采用了Broadway；

音频部分还没解决，但目前已经跑通视频部分；

使用JS实现RTMP协议直播；

2、利用nginx的rtmp模块

修改nginx的rtmp模块，参考师兄毕设；

3、MonaServer

待验证【4】

4、rtmp –> rtsp/rtp –> h5 video标签

待验证【5】

参考：

1、http://tech.lmtw.com/technews/201504/115637.html

2、http://my.oschina.nehttp://my.oschina.net/langhuihui/blog/612144

3、https://www.runjs.cn/p/h5rtmpclient/similar_projects

4、http://blog.chinaunix.net/uid-11344913-id-4976154.html

5、http://stackoverflow.com/questions/1735933/streaming-via-rtsp-or-rtp-in-html5

转载标明出处：https://blog.evanxia.com/2016/05/465

【总结】流媒体–待补充