作为开发者，我们需要有一个服务器来支持新视频行业的互联网化，有哪个开源方案能支持新爆发的业务？该方案需要支持哪些关键的能力或需求？本文由自阿里云RTC服务器团队负责人杨成立在LiveVideoStack线上分享的内容整理而成。

文 / 杨成立

整理 / LiveVideoStack

视频回放：

大家好，我是来自阿里云的杨成立，本次分享将会和大家详细介绍开源流媒体服务器的关键技术及未来发展。

我从2009年开始从事FFmpeg流媒体相关工作，2012年开始参与流媒体服务器的开发，2013年开始做开源流媒体服务器SRS，至今也有七年多的时间了。在这短短几年间，随着视频直播的爆发，SRS也迎来了快速增长。2017年我来到阿里云之后换成了WebRTC方向。我们可以看到目前Live WebRTC在整个视频的应用非常广，包括在线办公、在线教育、在线娱乐等各个行业都大展拳脚，音视频已经成为当前互联网交流与信息传播不可或缺的媒介手段。

这次的分享内容将主要围绕SRS的诞生与历程、SRS接下来的发展计划等，带领大家深入研究SRS存在的价值与意义。

得益于我国通信基础设施的日趋完善，尤其是Wi-Fi、4G网络的下沉普及，我国互联网市场音视频产品服务在2015～2018年经历了爆发式增长。当时消费者普遍拥有的可以观看视频的带宽大约为1M，网络环境较为稳定。

直播背后的技术早在功能机时代就落地成熟。例如2010～2012年，消费者主要通过PC上的Flash来观看网络直播视频，因为Flash可以跨主流PC端浏览器。而移动端尽管也支持Flash，但效果很不好。移动端如Android或iOS则主要支持HLS，早期Android对HLS的支持效果并不佳，后面有明显改善。

无论是传统PC时代还是现在的移动互联网时代，流媒体中主要使用的协议都是RTMP/FLV与Apple的HLS，流媒体播放器主要有Red5、NGINX-RTMP、CRTMP、Wowza、AMS等。大约是从2017年开始，Chrome中的Flash播放器就已经处于默认禁用的状态，后续Flash也会逐渐退出互联网历史舞台。

随着互联网的发展，移动端直播逐渐兴起并且成为主流。例如当前移动办公平台中的互联网直播：主要调用的是Native播放器，使用FLV协议。浏览器端则多采用HLS，二者共同构成了较为成熟完善的互联网直播协议体系。

随着移动基础网络的建设不断升级，移动端和IoT/5G时代来临，实时通信互联的需求日趋旺盛，Flash被禁用之后出现了更加完善的替代方案——H5播放器，其所使用的技术规范是MSE。H5播放器现可被绝大多数PC浏览器支持，同时H5也能播放FLV等格式。MSE扩展和Flash比较相似，提供的是JS接口，将FLV或HLS等解封装，然后打包为MP4后，送到MSE接口中播放。H5是替代Flash的标准方案，FLV、HLS、DASH等都可以直接通过MSE播放。

除此之外，大家所追求的另一个方向是低延迟直播，一般传输协议其延迟可达十几秒，而RTMP可以将延迟降低到3～5秒，公网上的TCP有时会出现抖动，此时延迟会变大。

目前大家都在探索更好的降低直播延迟的方法，在此方面WebRTC是大家公认的理想解决方案。尽管5G可以带来更低的延迟，但从通信角度来说可用性更加重要。5G网络的盛行意味着整个网络基础设施的稳定，有更多的通信设备可以达到相应要求。例如疫情期间使用视频直播的用户出现井喷式增长，而现有网络直播服务依旧未因此而出现重大宕机，这主要是得益于过去十多年的通信网络基础设施建设，以及整个开源环境、商业、云计算等领域的保障与进步相关。

目前SRT、IoT等的发展仍需面临很大挑战，特别是现在国内互联网的可能性不断丰富，直播产业生态环境也会趋于向好，新场景层出不穷。

首先，不同场景对网络基础设施以及整个商业环境的要求是完全不一样；其次，业务与开源往往是相互促进的，业务驱动新开源方案的不断落地实施，而开源方案也为业务提供技术支持；最后，不同行业之间往往存在很深的代沟，例如监控行业往往不会需要APP，而直播行业也不会用到私有协议。我们需要SRT做远距离传输、GB28181支持物联网接入，WebRTC开展互动和在线沟通。

我们希望有一套开源的解决方案能满足不同行业不同场景下的低延迟直播需求。现在的云计算有融合的趋势，无论是CDN还是云计算都开始逐渐满足在线直播的需求。作为开发者，我们需要有一个服务器来支持这些新视频行业的互联网化，有哪个开源方案能支持新爆发的业务？该方案需要支持哪些关键的能力或需求？

若想实现此开源流媒体服务器，我们需要考虑诸多关键约束和能力。

首先就是该平台需要具有一定伸缩性，也就是足够的弹性。互联网业务可以从局部扩展到很大的领域，如果我们使用开源方案则需要清晰意识到如果业务规模变大之后，现有资源与经验能否支撑起如此大规模的服务运行，这需要很多开发者的维护与云厂商的支持。如果没有开源平台和云厂商的支持，那么我们只能自主搭建平台并部署服务器。对于很多企业来说，他们不可能有能力和资源开展这么多业务，所以开源方案至关重要。

开源的前提是必须要有云计算的支持，现在能看到的CDN，包括阿里云和腾讯云等其实都支持RTMP、FLV、HLS，并且现在也开始支持WebRTC，在此基础上扩充生成了诸多商业落地应用，具备大规模应用的能力。我们自己基于开源方案搭建平台并将其对接到CDN上，即可妥善解决弹性问题。如果没有云服务的加持，开源平台的价值也无从谈起。

低延迟是我们需要注意的第二点。现在视频发展的一大趋势是低延迟，例如TCP类的协议其延迟可达3~5秒，这不仅仅是TCP协议本身所致。而像HLS切片、播放器延迟、编码延迟等都可能会提高延迟至8～10秒甚至更多。WebRTC通讯场景延迟一般小于一秒甚至可达400毫秒。常见的语音沟通场景延迟高于400毫秒就需要人工对两个人的讲话进行同步。

第三点是搭建的服务平台需要具备较为出色的易用性。如Red5、NGINX-RTMP、CRTMP、Wowza、AMS、Helix等。还有一项关键是协议之间的互通，一个业务可能需要基于多个协议，打通其中的隔阂至关重要。若想快速部署该方案，以上三点至关重要。

1. Scenario

1.1 互联网直播与连麦

互联网直播和连麦的应用场景想必大家并不陌生，其中一些技术细节值得我们重点关注。例如在编解码方面，H.264相对比较完善，而PC等设备上则有硬件编解码。商用编解码方面，比如国内的虹软、国外的HaiVision等，包括一些广电行业也有其自己的编解码器。除了编解码，再往上如推流OBS、FFmpeg等则主要被集成在系统当中。如果从主播端直接推流，那么基于OBS修改的方案比较多。

传输方面，我们需要把内容分发给许多观众，这一块的开源方案有NGINX-RTMP与SRS等，商业解决方案有Wowza和AMS等，商业解决方案更多是直接通过CDN网络直接进行分发。

播放器中的方案则主要是H5播放器，设备中大多会集成播放器来实现编解码，当然现在还有开源SDK来实现这一需求。直播连麦主要通过RTC与WebRTC的交叉功能来实现。

1.2 互联网实时通信

互联网实时通信的典型应用范例是视频会议，视频编解码方面与上一场景类似。但音频编解码方面，互联网直播多采用AAC而互联网实时通信则使用Opus，因为Opus的延迟更低。客户端包括推流与播放主要是WebRTC框架，推流与播放需要服务器，才能把流分发给很多人。此时大家会发现这里的服务器和前文提到的直播服务器完全不同，其支持Janus、Mediasoup、OWT与SRS等。在线会议场景中有一个特殊的应用就是等格式，我们希望实现电话之间的互联互通，这一块的开源方案是FreeSWITCH，其本身就是一个庞大的系统。

1.3 互联网媒体中心

互联网媒体中心作为一大应用场景，主要用于对内容的管控。例如当需要录制视频时，我们希望该视频可以被反复观看，如录制好的培训课程。还有一些内容并不会被频繁重复观看，如国庆直播、足球赛直播等，这里就需要设计对于已录制内容的妥善管控，如不良内容鉴定、自动剪辑等。媒体中心的设计和内容强相关，其需要包括转码、编码、存储等全流程的加持。传统方案是将媒体流传输给多个CDN或者借助CDN将流分发给多个CDN。此方案本身非常浪费资源，更好的方案是建立一个媒体中心。

安全方面，CDN也有播放的鉴权，例如限制一定的参与人数，对内容进行加密等，Token也是一种鉴权方式。除此之外，我们还需要一种接入标准如GB28181《安全防范视频监控联网系统信息传输、交换、控制技术要求》，尽管其属于一种标准，但非常私有，CDN不太好去支持该标准。云计算CDN更适合去做标准的事情，基础设施、分发等都需要标准来规范。如果接入协议非常私有，那么自建一套媒体中心更符合企业需求。将内容转换成标准协议发送至CDN或者其他企业，相对而言更加容易实现互联网化。

在特殊场景下，如为跨国直播设计的远距离传输当中，数据大多是通过专项网络进行传输，也可以走互联网或SRT。这些特殊的场景与业务强相关，并不太适合用统一的标准来框定，其规模不足够大也不能够成为标准。

2. Scalability——基于Cloud或对接CDN

上图展现了基于云部署或对接CDN的部署图，SRS的Demo网络就是这么部署的。其主要用K8s来部署，也可以用二进制来部署，包括边缘集群、媒体中心、源站等。流的输入端会退回非标准协议下的传输流，并将标准的RTMP流推送到源站。随后沿边缘CDN，经过RTMP、FLV等标准协议进行分发，如果规模不够大则直接从云机房当中播放分发，即便是切片协议也可以通过NGINX分发。因为数据可以对堆积到CDN，所以该系统具备伸缩能力。协议主要通过RTMP，也可以通过CDN，CDN现在也支持WebRTC，也可以通过RTC来对接，但RTC中有很多私有的东西，未来RTC可以走CDN，但还需要一定时间才能实现。

3. Latency

3.1 实时流媒体直播

关于延迟，SRS现在支持了WebRTC的播放，推流很快会被支持。上图视频画面显示的是一个时钟，OBS抓取时钟运行的画面。OBS本身有100毫秒左右的延迟，通过RTMP和WebRTC播放器播放该时钟运行画面，可以看到时钟指示数字出现明显不同，这也体现了二者的延迟差异。

3.2 实时流媒体系统

对GB28181进行测试，从上图实验结果我们可以发现，HIKVISION监控内网摄像头延迟为280毫秒、阿里云服务器WebRTC延迟约为210毫秒、阿里云服务器RTMP延迟1100毫秒。我们可以看到WebRTC服务器比内网监控摄像头的延迟还要低，出现这种情况主要是因为延迟并不单纯是网络问题。该场景下WebRTC延迟比监控还要低，且具备场景下载的能力。监控大多会走私有传输路线，传统方案若想正常播放则需要安装IE插件。而通过标准协议大家想要从手机端看到，手机只需要直接集成SDK，同时浏览器也可以直接看到画面，这样不需要安装任何插件，各个摄像头的流都可以看得到。

4. 举例

4.1 Cloud Native

第三部分是部署，SRS支持K8S和Docker部署，包括我们每个新发布版本都会支持Docker。上图主要展现了如何部署K8S，这里我就不再赘述，大家可以仔细观看相应文档。

以前我们主要通过二进制安装包来部署，其实SRS有多个镜像仓库，可以加速代码下载。仓库小下载速度也很快，编译、安装、启动等相对容易，其实Docker的部署方式更容易。最近陆陆续续有一些朋友反馈说编译存在一些问题，但Docker实际上可以在任何平台上部署，例如windows就完全可以部署Docker并运行，ARM平台上则可以交叉编译。有时需要我们解决的问题会比较多，但如果使用ARM的Docker编译就没有问题。因为Docker的环境是不变的，Docker是将环境、编译等问题统一解决，包括k8s等都可以在发布的时候实现不中断服务升级，业务低峰期时就可以发布新版本。

4.2 错误&日志

上图展示了SRS的日志，其中存在进程号与ID。一个ID代表服务器上的一个连接，一个服务器为成百上千个用户与进程提供服务，ID用于定位问题出现的位置与所属上下文日志。流媒体与HTTP不同，作为传输流存在上下文。长时间的数据交换使得其日志不仅仅只有一条，中间发生的事情都会通过日志来呈现。特别是RTC的日志非常多，如何从服务器中摘取关键信息？其实SRS设计了一套机制，也就是知道每个用户的日志究竟是什么，并及时从中摘取出。

除了日志之外，上图还展现了SRS中的错误反馈，错误参考了Go的机制，因为Go中出现错误可以Wrap打包错误，这样大家在反馈错误时就可以粘贴相应日志，就可以知道堆栈是什么。常规情况下出现错误只会呈现一个错误码，开发者并不知道究竟发生了什么。但如果有错误相应的堆栈以及给出每一层堆栈的变量，查询定位错误的过程就会变的非常方便。一般在关注一个新的开源项目时大家不太会关注这个问题。但当问题出现需要大家去查找问题源头时，堆栈的作用非常关键。这意味着我们不仅能够确定该问题的源头，也能妥善解决问题。

5. 高性能

性能是一项基础要求，一般情况下SRS的性能是其它服务器的两倍左右。对性能的要求在RTC中其实会更严苛，因为RTC的性能消耗更多。

6. SRS发展

关于SRS的发展，从2013年开始SRS一直都在稳步发展。初期由于应用场景相对固定，更新力度并不大。而现在，随着Original Cluster边缘集群相继得到支持，直播场景的覆盖也愈发完善，RTC也在不断发展。大家可以看到最近各个视频行业都在互联网化，因此最近SRS的活跃度也非常高。

2019年左右，SRS-Forks超越了NGINX-RTMP，预计未来SRS-Forks的增长是NGINX-RTMP的两倍。

回顾SRS的发展脉络，2013年v1.0实现了对直播基础协议的支持如RTMP、HLS等。随后的v2.0则主要支持FLV等以及移动互联网应用，v3.0则提供了对Original Cluster的支持，同时很早就提供了对边缘集群的支持，边缘集群主要应对很多人播放的场景。而Original Cluster则主要用于支持流播，例如监控摄像头等。边缘不会存储流而Original Cluster则会存储流，所以需要集群的存在，目前对直播场景的支持相对完善。

2020年初SRS支持了SRT，SRT主要用于解决远距离传输。同样也是用于直播与广电互联网化的综合场景，例如一些专业赛事、海外直播推流等。包括最近的GB28181、WebRTC等都能得到SRS的支持。

未来我们需要满足更广泛的互联网直播场景与需求，例如支持SFU、IoT、AI能力与云存储录制、安全以及MCU、SFU、AV1、SIP等。希望能够在2024年具备基本满足以上所有场景的能力。

感谢以上伙伴的卓越贡献

上图展现了我们现有的线上Demo，欢迎大家前来访问。