视频分发的方式和原理

Posted 2021-03-17 kali-bt

一：目前主流的视频分发协议

头条算是内容分发

流媒体分发方式以HLS和RTMP为主

RTMP指Adobe的RTMP(Realtime Message Protocol)，广泛应用于低延时直播，也是编码器和服务器对接的实际标准协议，在PC（Flash）上有最佳观看体验和最佳稳定性。

HLS指Apple的HLS(Http Live Streaming)，苹果公司提出的基于HTTP的流媒体网络传输协议，本身就是Live（直播）

HLS（Http Live Streaming）： 用于实时流传输的协议，HLS基于HTTP协议实现，传输内容包括两部分，一是M3U8描述文件，二是TS媒体文件。它的工作原理是把整个流分成一个个小的基于HTTP的文件来下载，每次只下载一些，当媒体流正在播放时，客户端可以选择从许多不同的备用源中以不同的速率下载同样的资源，允许流媒体会话适应不同的数据速率。

HLS的优势就是：可以自适应调整播放码流，即网络畅通时选择高码流，网络繁忙时选择低码流，二者可以随意自行切换，以保证视频流的流畅度。当然该方法需要服务器提供多码流视频数据了，还需在列表文件中注明，播放形式会根据用户实际情况来调整。直播的方式最好用hls的方式，因为它自己做了独立的功能模块，专门适用直播流。

二：基本概念

格式:

M3U: 本质上是音频文件的列表，纯文本格式。播放软件根据它的记录找到网络地址进行在线播放

M3U8: 是M3U中的一种，编码格式为UTF-8格式

TS片段：Apple 为了提高流播效率开发的技术，将流媒体切分成若干TS片段，然后通过一个m3u列表文件将这些TS片段集中起来供客户端播放器播放

HLS：HTTP Live Streaming是Apple的动态码率自适应技术。包括一个m3u8索引文件，TS媒体分片文件和key加密串文件。

TS文件选择原因：因为两个 TS 片段可以无缝拼接，播放器能连续播放。

HLS 对应的文件格式是 .m3u8 文件及对应的 .ts 播放文件，即服务器端会有一份 .m3u8 文件和其它很多的 .ts 文件，说得简单好理解一些是这样，m3u8文件是一个索引文件，ts为实际的播放内容。

以下内容了解就行：https://blog.csdn.net/weixin_38890593/article/details/96965164

ffmpeg 切割ts流的方法

有两种方式来切割，一种适合点播，一种适合直播。

一、segment方式

参数

-segment_list_flags +live ：表示直播，加此参数可当做直播来用，但不代表该方式适合直播。

segment_list_size ：对列表数量进行控制在6个。

该方式其实适合点播，因为它的ts流会被保存，相当于录制下来，如果你需要录制功能，那么此方法倒是变成了一个优势。

 

二、hls方式

直播的方式最好用hls的方式，因为它自己做了独立的功能模块，专门适用直播流。

目前新版本的ffmpeg的HLS模块加了很多参数，函数相关参考libavformat/hlsenc.c、 hls.c、 hlsproto.c

参数解析：

-re ：该参数表示ffmpeg将会按照当前视频的播放速率进行转码，这样就不会说切片的速度和播放速度不一致。不加这个参数，切片速度会非常快，客户端还来不及播放，列表已经被更新了。

-hls_time n ：设置每片的长度，默认值为2，单位为秒。

-hls_list_size n ：设置m3u8文件播放列表保存的最多条目，设置为0会保存有所片信息，默认值为5。一般用于直播流，点播文件可以设置成0，即全部保存。

-hls_wrap n ：设置多少片之后开始覆盖，设置为0则不会覆盖，默认值为0。这个选项能够避免在磁盘上存储过多的片，而且能够限制写入磁盘的最多的片的数量。

以上参数可以自己尝试调整看看效果。

上面两个命令就是制作m3u8文件的。

m3u8文件介绍

m3u8的直播和点播区别

1、直播没有#EXT-X-ENDLIST属性，因为是直播流，不会结束，否则就是点播了。

2、直播不断更新，移除前面的文件进行替换，且#EXT-X-MEDIA-SEQUENCE属性标签以步长为1进行递增。

 

不同的协议:

不常见的：

UDP：譬如YY的实时应用，视频会议等等，或者RTSP之类。这类应用的特点就是实时性要求特别高，以毫秒计算。TCP家族协议根本就满足不了要求，所以HTTP/TCP都不靠谱。这类应用没有通用的方案，必须自己实现分发（服务端）和播放（客户端）。

P2P：譬如RTMFP或者各家自己的协议。这类应用的特点是节省带宽。目前PC/flash上的RTMFP比较成熟，android上的P2P属于起步群雄纷争标准不一，ios上P2P应该没有听说过。

RTSP：这种不是互联网上的主要应用，在其他领域譬如安防等有广泛应用。

常见的：

HTTP progressive：早期流媒体服务器分发http文件时，以普通的http文件分发，这种叫做渐进式下载，意思就是如果文件很大譬如1小时时长1GB大小，想从中间开始播放是不行的。但这种方式已经是作古了，很多http服务器支持http文件的seek，就是从中间开始播放。

HTTP stream：支持seek的HTTP流，譬如各家视频网站的点播分发方式。或者稍微复杂点的，譬如把一个大文件切几段之后分发。目前在pc/flash上点播国内的主流分发是这种方式。

HLS：这种是现在适配方式最广（除了flash, 需要额外的as库支持），在PC上有vlc，Android/IOS原生播放器就支持播放HLS，html5里面的url可以写HLS地址。总之，在移动端是以HLS为主。

至于DASH/HDS，好像没有什么特别的理由，就像linux已经大行其道而且开放，其他的系统很难再广泛应用。

DASH/HDS是什么： 各家提出的HLS，目前还没有广泛应用。HDS：adobe自己的HLS，没啥用。

主流：

HLS：apple的HLS，支持点播和直播。

HTTP：即HTTP stream，各家自己定义的http流，应用于国内点播视频网站。

RTMP：直播应用，对实时性有一定要求，以PC为主。

 

总之，SRS支持HLS主要是作为输出的分发协议，直播以RTMP+HLS分发，满总各种应用场景。点播以HLS为主。

三：HLS主要的应用场景

跨平台：PC主要的直播方案是RTMP，也有一些库能播放HLS，譬如jwplayer，基于osmf的hls插件也一大堆。

HLS这种是现在适配方式最广（除了flash, 需要额外的as库支持），HTML5里面的url可以写HLS地址。总之，在移动端是以HLS为主。所以实际上如果选一种协议能跨 PC/Android/IOS，那就是HLS。Android/IOS原生播放器就支持播放HLS

IOS上苛刻的稳定性要求：IOS上最稳定的当然是HLS，稳定性不差于RTMP在PC-flash上的表现。

友好的CDN分发方式：目前CDN对于RTMP也是基本协议，但是HLS分发的基础是HTTP，所以CDN的接入和分发会比RTMP更加完善。能在各种CDN之间切换，RTMP也能，只是可能需要对接测试。

HLS作为流媒体协议非常简单，apple支持得也很完善。Android对HLS的支持也会越来越完善。

 

RTMP本质上是流协议，主要的优势是：

实时性高：RTMP的实时性在3秒之内，经过多层CDN节点分发后，实时性也在3秒左右。在一些实时性有要求的应用中以RTMP为主。

支持加密：RTMPE和RTMPS为加密协议。虽然HLS也有加密，但在PC平台上flash对RTMPE/RTMPS支持应该比较不错。

稳定性高：在PC平台上flash播放的最稳定方式是RTMP，如果做CDN或者大中型集群分发，选择稳定性高的协议一定是必要的。HTTP也很稳定，但HTTP是在协议上稳定；稳定性不只是服务端的事情，在集群分发，服务器管理，主备切换，客户端的支持上，RTMP在PC分发这种方式上还是很有优势。

编码器接入：编码器输出到互联网（还可以输出为udp组播之类广电应用），主要是RTMP。譬如专业编码器，或者flash网页编码器，或者FMLE，或者ffmpeg，或者安防摄像头，都支持RTMP输出。若需要接入多种设备，譬如提供云服务；或者希望网页直接采集摄像头；或者能在不同编码器之间切换，那么RTMP作为服务器的输入协议会是最好的选择。

系统容错：容错有很多种级别，RTMP的集群实现时可以指定N上层，在错误时切换不会影响到下层或者客户端，另外RTMP的流没有标识，切到其他的服务器的流也可以继续播放。HLS的流热备切换没有这么容易。若对于直播的容错要求高，譬如降低出问题的概率，选择RTMP会是很好的选择。

可监控：在监控系统或者运维系统的角度看，流协议应该比较合适监控。HTTP的流监控感觉没有那么完善。这个不算绝对优势，但比较有利。

RTMP的劣势是：

• 协议复杂：RTMP协议比起HTTP复杂很多，导致性能低下。测试发现两台服务器直连100Gbps网络中，HTTP能跑到60Gbps，但是RTMP只能跑到10Gbps，CPU占用率RTMP要高很多。复杂协议导致在研发，扩展，维护软件系统时都没有HTTP那么方便，所以HTTP服务器现在大行其道，apache/nginx/tomcat，N多HTTP服务器；而RTMP协议虽然早就公开，但是真正在大规模中分发表现良好的没有，adobe自己的FMS在CDN中都经常出问题。

• Cache麻烦：流协议做缓存不方便。譬如点播，若做RTMP流协议，边缘缓存RTMP会很麻烦。如果是HTTP，缓存其实也很麻烦，但是HTTP服务器的缓存已经做了很久，所以只需要使用就好。这是为何点播都走HTTP的原因。

 

 

HLS的主要优势是：

性能高：和HTTP一样。

穿墙：和HTTP一样。

原生支持很好：IOS上支持完美。Android上支持差些。PC/flash上现在也有各种as插件支持HLS。

HLS的主要劣势是：

实时性差：基本上HLS的延迟在10秒以上。

文件碎片：若分发HLS，码流低，切片较小时，小文件分发不是很友好。特别是一些对存储比较敏感的情况，譬如源站的存储，嵌入式的SD卡。