开源流媒体服务器：为何一定得再撸个新的( 二 ) _流媒体服务器

我们希望有一套开源的解决方案能满足不同行业不同场景下的低延迟直播需求。现在的云计算有融合的趋势，无论是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. Scenario1.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 。此方案本身非常浪费资源，更好的方案是建立一个媒体中心。