直播技术简述

0 引言

本博客是关于网络直播简述，是后续直播技术详解的开端，以下都是本人亲身经历和切身感受。此博客秉承以下原则：

• 没有原理性介绍，我不是这个工具的作者，写了也是抄的。
• 没有太详细的操作步骤，操作步骤尽量指向官方文档。
• 没有遇到的或者不值一提的，我都不会写上去。

作者	Daniel.Leung
组织	池鱼 - YiiGaa
邮箱	[email protected]
日期	2019-01-28

1 背景

随着时代的进步，时代对于信息载体的倾向开始从原来的图文信息向音视频信息转变。由于相对于图文的信息，音视频信息更具感官性，所以现代社会更倾向于以视频（短视频）、直播等音视频信息作为信息传播的载体。2016年起，直播的热潮开始席卷全国，各式各样的直播平台推陈出新。
如果以技术的角度看这种变化的话，我们也进入了云计算时代。从原来的云资源（主要是云存储）到现在的云计算（视频、直播需要各种转码）。从原来的服务器包年包月收费，也转变到按计算量收费（如现在的腾讯云点播服务，是以转码时长收费的，其实这就是按计算量收费）。
把视角拉回到直播，直播平台搭建的需求量这里不作分析（主要是我并不是一个销售…）。以下介绍的是直播技术的叙述，这些都是我的切身体会。

2 总体介绍

2.1 直播平台流程图

推流

推流

拉流

拉流

采集端

服务器

CDN

观看端

• 采集端，可以是手机（可以用易推流）、PC（可以用OBS）。一般采集端生成RTMP协议的视频流，推送到服务器端。如果要开发推流软件的话，也可以用相关的SDK。
• 服务器，服务器需要做三件事情：① 接收RTMP流；② 视频流转码；③ 视频收录；
  – 接收RTMP流，一般使用SRS（smple rtmp server），除了这个服务，还有其他如NGINX、WOWZA。详情可见SRS官方介绍中的compare。
  – 视频流转码，从接收RTMP流的服务（如SRS）拉取视频流，并生产出新的视频流。最直观的作用是，观看直播的时候可以选择流畅、高清、超清等。
  – 视频收录，如果说特定的直播场景不需要收录的话，可以不做这一步。但是这个是有相关规定的，带有运营、传播的直播都需要把收录收录保存15天（具体多少天忘了…）。
• CDN，会缓存服务器生产的直播流（服务器的视频流到CDN有两种方式，推流和拉流，具体根据服务器生成的直播流协议决定，如果服务器生产的是RTMP视频流，可以推流到CDN的服务器，如果成产的是HLS视频流，就需要CDN服务器从服务器拉取HLS视频流），十几二十万的直播观看端就靠这个扛住压力的。
• 观看端，观看端作为直播的消费端。注意，这里的观看协议与服务器是否生产RTMP视频流无关，CDN可以配置把RTMP视频流转成HLS视频流，最终于CDN提供的视频流协议决定。

2.2 直播服务

背景里说到现在向云计算量消费转变，对于直播，也会有云直播的服务供应，如网易云视频、腾讯云都有提高直播服务。只要购买套餐，就能免去2.1中直播流程的服务器和CDN的相关开发，甚至采集端和观看端都会有成套的SDK，嵌入即可使用。但是，系统的业务还是要开发的。这种方式我也使用过，只要调用好相关API，就可以完成直播的控制了，还是相当简单的，但是稳定性和私密性的话，是不受控的。这种方式这里不做多叙述。

3 详细介绍

3.1 采集端

• 现成软件，手机（可以用易推流）、PC（可以用OBS），嵌入式相关的话，也有直接生产RTMP流的摄像头模块。
• 协议，一般使用RTMP，这个协议会把音视频数据打包成固定长度的包，以100微妙的速率把包发到服务器。但是RTMP是基于TCP的。在采集端预设在网络不稳定、或延迟有限制的环境时，tcp的方式会造成阻塞，这时候一般使用udp的推送方式。但是大多数情况下，使用RTMP即可。除了这个协议以为，还有RTSP等，但这个协议我没使用过。
• 视频格式，在开发采集端的时候，无论使用场景网络如何，都需要限制码率（一秒钟最大的视频流大小），如果不限制码率的话，可能造成视频卡顿。

3.2 服务器

• 接收RTMP流，如果采集端采集生成的是RTMP流的话，需要有接收RTMP的服务器。现在比较流行的是SRS（smple rtmp server）。无论性能和功能都是比较领先的，不仅支持分布式部署，如果没有高度业务控制的话，还可以通过服务配置完成视频流转码和收录。除了这个服务，还有其他如NGINX、WOWZA。详情可见SRS官方介绍中的compare。
• 视频流转码，最直观的作用是，观看直播的时候可以选择流畅、高清、超清等。一般视频转码用FFmpge，强大的命令行可以让各种语言（JAVA、Python）等以命令行实现各种功能（视频转码、合并、剪切等）。如果希望用程序调用FFmpeg的库函数的话，那只能用C或者C++完成这件事情，而且如果选择这条路的话，分析源码成为了唯一的出路。不过使用命令行的方式在问题发生的时候还是需要看源码的，因为FFmpeg确实还有bug在里面…
• 如果是延迟要求极高的话，一般是不转码的，因为转码带来了很大的计算损耗。
• 视频收录，直播收录可以用SRS直接配置收录位置，也可以用FFmpge把视频流转成视频文件。收录一般用FLV，因为flv是每段数据都有头信息，一旦程序中断也不会造成视频播放不了的问题。而MP4是只有一个头信息的，只有在视频生成完成后才写入，一旦程序意外中断会造成视频损坏，不能播放等问题。

3.3 CDN

• 服务器的视频流到CDN有两种方式，推流和拉流，具体根据服务器生成的直播流协议决定，如果服务器生产的是RTMP视频流，可以推流到CDN的服务器，如果成产的是HLS视频流，就需要CDN服务器从服务器拉取HLS视频流。这里值得一提的是，目前CDN一般只支持推流的方式，拉流方式的CDN只有腾讯云有提供。
• 对于服务器而言，如果是拉流的话，消费者只有一个，就是CDN，当然，如果有4个CDN点的话，就是4个消费者。而真实的观看人数与服务器是没有直接的关系的。
• 服务，CDN只能用阿里腾讯（现在全国只有十几个供应商有CDN的牌照）等运营商的服务，它为你部署了全国的分发点和提供了强大的带宽，可以扛住十几二十万的在线观看。
• CDN服务还可以设置转换协议，可以自动转成HLS等对HTML5比较有友好的协议。
• CDN一般是按流量包收费的。

3.4 观看端

• 协议，如果是直播延迟有高度的要求，只能用RTMP。但是如果是普通的直播的话，应该顺应Safari和Chrome对flash的摒弃，使用现在比较适合HTML5的HLS。除了HLS，也可以使用HTTP-FLV，使用fls.js的话可以在不使用flash的情况下播放flv的直播流。
• 延迟，HLS>HTTP-FLV>RTMP。其中HLS会有十几二十秒的延迟。
• 这里的观看协议与服务器是否生产RTMP视频流无关，CDN可以配置把RTMP视频流转成HLS视频流，最终于CDN提供的视频流协议决定。

4 后记

直播，数据挖掘等，让我们逐渐进入云计算时代。计算量也会逐渐成为资源被使用。欢迎进入云计算时代，也请为越拉越长的技术栈而无休止地学习。