不同音视频传输协议的对比

一、直播

直播场景通常使用的有hls协议、http-flv渐进式传输、RTP协议、DASH协议、RTMP协议,当然还有一些公司自己研发的私有(一般是UDP)协议。此外还有一些较少为人所知的HDS(adobe出品的与hls/dash匹配的码率自适应协议HTTP Dynamic Streaming)、SSTR/MSS(微软出品的码率自适应协议Smooth Streaming Transport Protocol)

各个协议对比:

协议 传输层 客户端支持 优势 劣势
hls HTTP短连接 ios/android端及H5原生支持,flash/PC端等需要自研播放器 支持广泛,HTTP请求支持简单,网络兼容性好,码率自适应,服务端及CDN支持好 延时太长,10s以上,单分片文件较小不便存储
http渐进式传输 HTTP长连接 flash支持,ios/android/PC端/H5需要自研 延迟相对较小,HTTP请求简单,网络兼容性好,服务端及CDN支持好 容易被劫持,多端兼容较为麻烦
rtp UDP Android端支持,其他各端都需要自研 延迟小 服务端逻辑复杂,协议及控制协议较难理解,开发周期长,客户端支持很难
dash HTTP短连接 H5原生支持,其他端需要转换格式 开放标准支持广泛,码率自适应 服务端及商业CDN支持不够,使用不广泛
rtmp TCP长连接 flash支持,其他需要自研 延迟较小 服务端压力相对较大,协议较为复杂,客户端兼容播放麻烦
私有协议 UDP 完全需要自研 延迟可以做到很小,保密性较好,业务自行扩展性高 开发难度极其大,客户端/协议定义/流服务端及CDN都需要自行开发支持,传输可靠性难以保证

多说一句:上面表格中传输层一列,并不是指该种传输方式对应的传输层协议(实际上传输层应该就是我们说的UDP/TCP),而是我们工作场合便于理解,常提到的传输和连接方式(有的是介于传输层和应用层的)。比如HTTP短连接和HTTP长连接,其实HTTP严格来说是基于TCP的应用层协议,但TCP连接的通道可以保持一段时间不关闭,这样就实现了“所谓的”HTTP长连接。实际上对于HTTP而言,就是完成HTTP REQUEST和HTTP RESPONSE,但如果传输层的TCP连接未断开,则可以仍旧在这个通道中继续request和response。

目前国内互联网直播使用协议场景:

业务场景 使用协议情况
web端直播 http-flv,rtmp,hls都有使用。一般如果结合P2P使用,会选择flv和hls
移动端互动直播 较多使用http-flv,个别厂家使用私有协议
移动端大型直播 较多使用http-flv和hls
web端推流 主要使用rtmp,少数使用rtp
移动端推流 主要使用rtmp,少数使用rtp,个别厂家使用私有协议

个人比较看好dash的发展,标准总是需要统一的嘛,但感觉要10年后了。。。

二、点播

点播的协议有hls,DASH,常见的基于http传输的mp4和flv,以及部分公司的私有协议。

写到这里我突然觉得confused。网上一大坨都是直接拿mp4/flv和hls并列对比,你说怎么能把mp4、flv和hls放一起对比呢?感觉不对呀!!确实我们通常是基于http协议来传输mp4和flv,但说白了mp4和flv是一种封装音视频的标准(是一个盒子),应该对应hls协议里面的ts/fMp4、DASH的mpd这些嘛,而且我们也可以用私有协议来传输mp4和flv呀。但是为了便于理解,我们沿用这种奇怪的对比方式

各个协议对比:

协议 传输层 客户端支持 优势 劣势
mp4 一般http 广泛支持 各种设备及服务端、CDN都通用 文件头过大且会累积
hls http H5/iOS/android原生支持,其他需要自研 码率自适应,直播切点播时可以实时生成 拖拽可能不够精准,对于超长点播可能分片较多
flv 一般http flash支持,ios/android/PC端/H5需要自研 格式简单 多端兼容略微麻烦
dash http H5原生支持,其他需要转换 码率自适应,标准规范 服务端及CDN支持不够,使用不广泛
私有协议 udp 同直播 与直播不同的是,更多的结合P2P使用,用于合理利用带宽 同直播

目前国内通常使用搭配:

  • 1).短视频播放——用整段mp4的较多
  • 2).与直播无关的长视频播放——用分段的mp4/flv较多;也有少数厂家开始使用HLS/DASH,但由于码率自适应对客户端的适配要求以及服务端转码要求不低,所以并没有被真的广泛使用;有技术积累的厂家会用私有协议传输,叠加P2P
  • 3).直播生成的回放——用hls较多。因为hls可以在直播过程中就转码切片生成ts,而且可以实现直播实时观看回放(*但这种情况不适用于互动直播)。当然也可以考虑使用分段的mp4/flv,但是这样在直播结束时需要更新最后的文件头,以及直播转回放的URI查询接口,会比较麻烦,也不适用于直播实时观看回放的场景。

对于mp4和hls,有一种方法可以结合二者的优点,具体见文章MP4大文件虚拟HLS分片技术,避免点播服务器的文件碎片

你可能感兴趣的:(不同音视频传输协议的对比)