目前直播技术汇总及低延时直播的方案汇总

码客说

发布于 2021-01-20 10:07:53

5.2K0

发布于 2021-01-20 10:07:53

文章被收录于专栏：码客码客

前言

现在常见的直播常见的解决方案有

RTMP/HTTP-FLV
WebRTC
RTSP
HLS

HLS：延迟主要来自编码解码时产生延迟、网络延迟、CDN 分发延迟。由于它是切片协议，延迟分两大块，一个是服务端有切片缓冲延迟，另一个是在播放端防抖缓冲会有延迟。切片的大小和数量都会 HLS 影响延迟大小，一般在十秒以上。

RTMP/HTTP-FLV: 目前国内大部分厂家在用的 RTMP，它相对于 HLS 在服务端做了优化。RTMP 服务端不再进行切片，而是分别转发每一帧，CDN 分发延迟非常小。RTMP 延迟主要来自播放端防抖缓冲：为提升弱网环境下抖动时直播的流畅度，缓冲延迟一般有五到十秒。

这两类协议都是基于 TCP，国内厂商基本上已经将 RTMP over TCP 的延迟做到的极致，如果一个协议仍然基于 TCP 优化延迟，效果上很难优于目前的 RTMP 。

播流浏览器不支持RTSP，需要浏览器播放的可以放弃RTSP了

推流时只有WebRTC支持网页端推流

TCP/UDP

RTMP是通过TCP传输。
RTSP音视频流数据可以用TCP或者UDP来传输。
WebRTC是基于UDP协议的。

RTMP可以借助流CDN扩展用户数量,市面上的CDN流服务大部分都只支持RTMP

TCP/UDP

什么时候使用UDP

网络带宽需求较小，而实时性要求高；
大部分应用无需维持连接；
需要低功耗；

采用TCP，一旦发生丢包，TCP会将后续包缓存起来，等前面的包重传并接收到后再继续发送，延迟会越来越大。基于UDP的协议如WebRTC是极佳的选择。

WebRTC

基于端对端的webrtc直播的方式不适合直播场景一对多可以基于媒体服务器的webtrc直播

WebRTC一般是用来做点对点双向视频语音聊天的，比如微信视频，直播并不需要双向视频，直播一般是一对多，只有单边视频，webrtc里面的语音处理，比如回声消除，噪音抑制，自动增益等在直播中没有作用。

网上大都说的是WebRTC主要用于端对端的时候，比如人数较少的视频会议使用，但实际上已经有很多厂家已经使用WebRTC做了直播的方案。

腾讯课堂(http://ke.qq.com)已经上线了webrtc的1对多直播方案。

但是改造成本相对传统直播方案较大。但是带来的收益也是比较明显的，在延迟，首帧，弱网卡顿等方面都有比较大的提升。可以实现毫秒级时延。

chrome里面的那部分webRTC(javascript)、要在服务器端(云端)用nativeRTC(C++)来开发

直播流程中参与的节点主要有三个：直播发起端、流媒体服务器和播放终端。

直播发起端的实现相对简单，可以使用js脚本，利用浏览器的WebRTC API来实现视音频的采集、合成、编码和传输，也可以使用的Android或iOS的WebRTC SDK来实现。有一定js开发能力或app开发能力的程序员可以胜任这部分工作。

流媒体服务器的开发相对是个难点，需要能够处理WebRTC信令、接收RTP协议并进行协议转换后对外提供大并发的直播输出。如果要想降低开发周期和投入，可以使用现有的成熟产品，例如可以选择国内的流媒体服务器软件NTV Media Server G3，这个系统在协议转换和播出能力上表现都是不错的。

无论采用哪个产品，服务器上的实现功能应该是一致的，即： WebRTP协议适配、音视频流接收、协议重新复用、播出。

播放终端的工作相对较小，通过流媒体服务器适配后，一般终端不需要做任何改进，可以继续使用原有的协议和方法进行播出，例如http-flv协议或hls协议。当然也可以开发WebRTC的播放终端。

WebRTC跨平台支持得比较好，延迟比较低，但入门难度比RTMP高

目前开源的主流WebRTC媒体服务器如下：

Kurento (https://github.com/Kurento/kurento-media-server) (C++)
licode (https://github.com/lynckia/licode) (NodeJS)
janus (https://github.com/meetecho/janus-gateway) (C)

客户端API

https://developer.mozilla.org/zh-CN/docs/Web/API/WebRTC_API

优点：

相对于端对端的WebRTC方式，避免了客户端性能低、音视频处理、内容审核等问题，支持更为复杂的应用场景；
支持多人进行同时观看直播，并发度高；
在web端集成相对简单容易，采用浏览器即可接入，且延时较低；

缺点：

该种方式相对于端对端的webrtc方式，开发成本较高，需要实现自己的媒体服务器，而目前没有比较成熟的方案。
相对于成熟的rtmp配套解决方案，周边设施相对较少。

RTMP相关

服务端

nignx+nginx-rtmp-module
srs
livego
node-rtsp-rtmp-server

推流

1、rtmp发布h264裸数据

librtmp比较常用，但是不好用，还是整理了下

https://blog.csdn.net/firehood_/article/details/8783589

linux版

https://files.cnblogs.com/files/dong1/librtmp_pusher.tar.gz

windows版

https://files.cnblogs.com/files/dong1/librtmp_pusher_win.zip

2、发布h264 rtmp最省事的还是srs-librtmp

开源srs自带的示例srs_h264_raw_publish.c就很容易用起来

我导出了srs-librtmp项目，做了两个demo，分别跑在x86和arm

附件：https://files.cnblogs.com/files/dong1/srs-librtmp_pusher_demo.zip

具体细节可以看看调试笔记

https://www.cnblogs.com/dong1/p/10600115.html

3、直接用ffmpeg

https://github.com/Akagi201/ffmpeg-push

整理了下，可以推送文件和url网络实时流

https://files.cnblogs.com/files/dong1/ffmpeg_push.zip

./main source.200kbps.768x320.flv rtmp://182.61.45.149:1935/live/movie ./main rtsp://admin:12345@172.16.23.142:554/H.264/ch1/main/av_stream rtmp://182.61.45.149:1935/live/movie

4、下面这个有音频和视频两路数据，比较方便

This tool is used to encapsulate H264 and AAC to RTMP

https://github.com/rainfly123/flvmuxer

5、封装成ts也可以

ts muxer

https://github.com/felix-001/tslib

拉流

ffmpeg
python-librtmp

RTMP延迟优化

推流端->RTMP服务端->拉流端

那么针对这个流程，我们可以看出主要的延迟只会在这三个地方发生，那么我们来分析哪些地方可能造成延迟变大。

推流端

对于一个推流端，首先涉及到的就是编码，也就是对视频流进行封装。这里涉及到一个重要的概念GOP，指的是视频中两个I帧的间隔。那么我们先了解一下视频编码中的I帧、B帧和P帧。

I帧、B帧、P帧

我们知道视频或者说是动画利用的是人眼的视觉残留的原理，通过一系列的图片，达成动画的效果。所以视频传输本质上也是传输了一帧帧的画面数据。

那么如果我们每一帧的画面都是完整的画面，大概需要多少数据呢？我们假设我们呢传输的是1080P的8bit图组成的视频，那么每一帧就是1920x1080x8x3=49766400‬bit,也就是47.46MB，那么如果视频帧率是30Hz，那么每秒也就是1423.82MB。也就是在这种情况下，我们每秒传输的数据就是1.39MB。这个数据量其实在很多情况下是比较大的，试想如果观看这样的视频10分钟，那么流量就是834MB。

为了解决这个问题，目前视频传输和保存都采用了视频压缩技术，比如H.264。在这种技术下，编码器将图片分成三种，也就是I帧、B帧和P帧：

I帧：也就是关键帧（Intra-coded picture 内部编码帧），指的是完整的画面，在这个帧中，有着完整的画面信息。
B帧：双向内插帧（Bidirectional predicted picture 双向参考帧），这个画面是不完整的，如果想要依靠这个画面得到完整的画面信息，那么就需要参考前一帧和后一帧。这个是包含画面信息最少的帧。
P帧：前向预测帧（Predicted picture 预测帧），这个画面也是不完整的，如果想要依靠这个画面得到完整的画面信息，需要参考前一帧。

而视频编码就是生产一个个GOP（Group of Picture），也就是包含一个关键帧I帧的一组图片。而GOP长度就是两个I帧的距离。那么GOP对延迟有什么影响呢？因为GOP的存在，导致播放端的视频解码器需要那倒关键帧才能解码，如果一开始拿不到关键帧，那么解码器只能等待，这时就会出现黑屏，一直等到关键帧的到来。而这个最长时间是多少呢？就是一个GOP的长度。

所以为了防止黑屏的出现，很多时候服务端都会缓存前一个GOP，这就导致客户端始终从前一个I帧播放，那么延迟至少是一个GOP的长度。这时很多朋友肯定会想那么我们就减少GOP的长度不就可以了么？这个想法的确是对的，很多实时性要求很高的地方就是这么做的，之所以不是所有场景都这么做，是因为GOP太低会导致编码率压缩率变低，图像质量也没有那么好。

缓存

因为RTMP是基于TCP的，所以存在累积延迟的问题，也就是在网络条件不好的时候，为了保证传输的可靠性，会将失败的包保存起来，等待网络条件好的时候一并发出。但是对于直播来说，这样无疑增加了延迟，如果网络波动较大，那么缓存反而是有害的，所以一般来说都会将推流端的缓存设置到尽可能的小。

RTMP服务端

对于服务端来说，需要考虑的首先和上面一样，也就是缓存，如果是低延时要求，那么首先服务端的缓存也不能设计过大。那么除了缓存服务端还需要考虑上面呢？

Merged-Read

RTMP的读效率非常低，首先要先读一个字节，判断是哪个chunk，然后读取header，再读取payload。所以一般为了提高性能，服务端会采用merged-read,也就是一次读取几毫秒的数据，进行一次读取。这样的坏处就是服务端至少要接受到这么多数据才能进行读取，而这个就是延迟的大小。所以如果是低延时的场景，那么就需要关闭这个功能，让服务端每次收到一个包就解析。

Merged-Write

同样，服务端为了提供效率，也会进行merged-write,也就是一次发送几毫秒的数据到客户端，这个同样也会导致延迟。好处是可以支持的客户端会变多。所以在低延迟的场景中我们需要根据要求进行权衡，将这个设置到较小的值。

GOP

结果推流端的内容，服务端应当关闭GOP缓存，不缓存前一个GOP。

累积延迟

同样，因为拉流端可能采用RTMP或者HTTP-FLV，也都是基于TCP的，所以会存在累积延迟，处理这个问题的解决方法就是减少缓存区的大小，如果发现太多的缓存就丢弃。

拉流端

拉流端要考虑的其实就是一个，那就是缓存的设置以及缓存的策略。这里因为不是专业的，只能说一下思路，就是获取缓存的长度和当前播放的位置，然后两者的差就是具体的延迟。所以需要设置个阈值，当大于这个值时，就进行动态的快进。这样就可以达到无感知的延迟缩小。

总结

通过上面分析，我们可以看出，RTMP中的延迟是无法避免的问题，我们能做的就是尽量根据需求来权衡延迟和性能。而这里面最重要的就是缓存，缓存的好处就是稳定，但是它的坏处也很明显，那就是带来延迟的增加。

大牛直播SDK联合创始人的结论

RTMP延迟大，主要在采集推送端，和播放端处理上，特别是播放端，目前的RTMP播放器都说开源的框架改的，延迟确实降低不下来。

低延时直播方案

适用场景

教育直播大班课可以支持超大数量规模的同学同时在线低延时与老师互动。
电商直播实时与买家互动答疑，交流商品信息。
体育直播精彩竞技、电竞等赛事，让观众实时了解现场情况。
互动娱乐及时反馈增强互动，极大优化了观众送礼时的嘉宾反馈互动体验。

上面的方案适合直播的基本都是RTMP和WebRTC两个中选择。

但是

延迟上WebRTC优于RTMP，WebRTC可以做到延迟低于1秒，RTMP一般在1秒以上基本都在2到10秒之间完善程度RTMP优于WebRTC

我们对低延迟直播技术的未来展望有三点：

现在的 WebRTC 开源软件还不能很好支持直播，希望未来的标准 WebRTC 能很好直播，这样我们可以很方便的在浏览器上做低延迟直播。
5G 到来后，网络环境会越来越好，低延迟直播技术会成为直播行业未来的一个技术方向。
现在各厂商的低延迟直播协议大都存在私有协议，对用户来说，从一个厂商切换到另一个厂商时成本会很高。低延迟直播协议的统一、标准化对直播行业非常重要。一个基本判断是，随着低延迟直播技术的方案和普及，低延迟直播协议在未来一定会走向统一化和标准化。也希望我们国家的技术厂商能够在推动低延迟直播标准化的过程中发出自己的声音，贡献自己的力量。

厂商的选择

即构科技(RTMP)

当初也考虑过使用WebRTC来做视频直播，但是后来经过调研后放弃转而使用RTMP来做视频直播。原因是在国内有60%的浏览器不支持WebRTC，而且主推WebRTC的Google Chrome在国内的效果也大打折扣。RTMP其实也不是最优的选择，但是我们最终还是选择了RTMP，为什么呢？因为RTMP是标准协议，能被众多CDN网络支持，能兼容客户的老系统。尽管RTMP比较难做到比较低的延迟，但是经过我们不断的死磕，还是创造了奇迹，在主播端做到400毫秒延迟，观众端1秒左右的延迟。其实最适合做视频直播的是UDP协议，容易做到比较低的延迟，可惜基于UDP的私有协议在兼容性上面有先天不足，因此我们最后舍弃，而是使用它作为互补的方案，在网络比较差的时候才使用基于UDP的私有协议来推流，平时还是使用RTMP。在即构科技给花椒直播，一直播和么么直播这些直播大厂服务的过程中，我们更是庆幸当初选择协议的时候做了正确的决定。如果我们采用WebRTC，这些大厂不管我们效果有多好，都不会选择我们的。

因此，如果你要求覆盖比较广的用户面，确保你的直播平台有普适性，实在不建议用WebRTC。请多做一点测试比较，就能验证我上面描述的情况。

腾讯课堂(WebRTC)

腾讯课堂(http://ke.qq.com)已经上线了WebRTC的1对多直播方案。

但是改造成本相对传统直播方案较大。但是带来的收益也是比较明显的，在延迟，首帧，弱网卡顿等方面都有比较大的提升。可以实现毫秒级时延。

淘宝直播(WebRTC)

RTS 是由阿里云和淘宝直播共建的低延迟直播系统，此系统分两大块：

上行接入：可接入三种输入方式，第一种是 H5 终端，使用标准 WebRTC 推流到RTS系统中；第二种是 OBS 等传统 RTMP 推流软件，使用 RTMP 协议推流到 RTS 系统中；第三种是低延迟推流端，可以使用我们基于 RTP/RTCP 扩展的私有协议推流到RTS系统中。
下行分发：它提供两种低延迟分发，第一种是标准WebRTC 分发，另一种是我们在 WebRTC 基础上的私有协议扩展，淘宝直播目前使用最多的就是基于私有协议的分发。

阿里的低延迟直播：官方文档

低延时直播RTS（Real-time Streaming）在阿里云视频直播（ApsaraVideo Live）的基础上，进行全链路延时监控、CDN传输协议改造、UDP等底层技术优化，通过集成直播播放端SDK，支持千万级并发场景下的毫秒级延时直播能力，弥补了传统直播3~6秒延时的问题，保障低延时、低卡顿、秒开流畅的极致直播观看体验。