0 引言
本博客是关于网络直播简述,是后续直播技术详解的开端,以下都是本人亲身经历和切身感受。此博客秉承以下原则:
- 没有原理性介绍,我不是这个工具的作者,写了也是抄的。
- 没有太详细的操作步骤,操作步骤尽量指向官方文档。
- 没有遇到的或者不值一提的,我都不会写上去。
作者 | Daniel.Leung |
---|---|
组织 | 池鱼 - YiiGaa |
邮箱 | YiiGaa@126.com |
日期 | 2019-01-28 |
1 背景
随着时代的进步,时代对于信息载体的倾向开始从原来的图文信息向音视频信息转变。由于相对于图文的信息,音视频信息更具感官性,所以现代社会更倾向于以视频(短视频)、直播等音视频信息作为信息传播的载体。2016年起,直播的热潮开始席卷全国,各式各样的直播平台推陈出新。
如果以技术的角度看这种变化的话,我们也进入了云计算时代。从原来的云资源(主要是云存储)到现在的云计算(视频、直播需要各种转码)。从原来的服务器包年包月收费,也转变到按计算量收费(如现在的腾讯云点播服务,是以转码时长收费的,其实这就是按计算量收费)。
把视角拉回到直播,直播平台搭建的需求量这里不作分析(主要是我并不是一个销售…)。以下介绍的是直播技术的叙述,这些都是我的切身体会。
2 总体介绍
2.1 直播平台流程图
- 采集端,可以是手机(可以用
易推流
)、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 后记
直播,数据挖掘等,让我们逐渐进入云计算时代。计算量也会逐渐成为资源被使用。欢迎进入云计算时代,也请为越拉越长的技术栈而无休止地学习。