一文读懂主流视频直播系统的推拉流架构、传输协议等 |
您所在的位置:网站首页 › 直播平台推流是什么意思呀 › 一文读懂主流视频直播系统的推拉流架构、传输协议等 |
1、引言
随着移动网络网速的提升与资费的降低,视频直播作为一个新的娱乐方式已经被越来越多的用户逐渐接受。特别是最近这几年,视频直播已经不仅仅被运用在传统的秀场、游戏类板块,更是作为电商的一种新模式得到迅速成长。本文将通过介绍实时视频直播技术体系,包括常用的推拉流架构、传输协议等,让你对现今主流的视频直播技术有一个基本的认知。 2、蘑菇街的直播架构概览目前蘑菇街直播推拉流主流程依赖于某云直播的服务。云直播提供的推流方式有两种: 1)一是通过集成SDK的方式进行推流(用于手机端开播);2)另一种是通过RTMP协议向远端服务器进行推流(用于PC开播端或专业控台设备开播)。除去推拉流,该云平台也提供了云通信(IM即时通讯能力)和直播录制等云服务,组成了一套直播所需要的基础服务。 3、推拉流架构1:厂商SDK推拉流
这种推拉流方式有几点优势: 1)只需要在客户端中集成SDK:通过手机就可以开播,对于主播开播的要求比较低,适合直播业务快速铺开;2)互动直播后台仅做转发:没有转码,上传CDN等额外操作,整体延迟比较低;3)主播端和用户端都可以作为音视频上传的发起方:适合连麦、视频会话等场景。 4、推拉流架构2:旁路推流 之前介绍了通过手机SDK推拉流的直播方式,看起来在手机客户端中观看直播的场景已经解决了。那么问题来了:如果我想要在H5、小程序等其他场景下观看直播,没有办法接入SDK,需要怎么处理呢? 这个时候需要引入一个新的概念——旁路推流。旁路推流指的是:通过协议转换将音视频流对接到标准的直播 CDN 系统上。 目前云直播开启旁路推流后,会通过互动直播后台将音视频流推送到云直播后台,云直播后台负责将收到音视频流转码成通用的协议格式并且推送到CDN,这样H5、小程序等端就可以通过CDN拉取到通用格式的音视频流进行播放了。 随着直播业务发展,一些主播逐渐不满足于手机开播的效果,并且电商直播需要高保真地将商品展示在屏幕上,需要通过更加高清专业的设备进行直播,RTMP推流技术应运而生。 我们通过使用OBS等流媒体录影程序,对专业设备录制的多路流进行合并,并且将音视频流上传到指定的推流地址。由于OBS推流使用了RTMP协议,因此我们称这一种推流类型为RTMP推流。 我们首先在云直播后台申请到推流地址和秘钥,将推流地址和秘钥配置到OBS软件当中,调整推流各项参数,点击推流以后,OBS就会通过RTMP协议向对应的推流地址推送音视频流。 这一种推流方式和SDK推流的不同之处在于音视频流是直接被推送到了云直播后台进行转码和上传CDN的,没有直接将直播流转推到用户端的下行方式,因此相比SDK推流延迟会长一些。 劣势主要是: 1)OBS本身配置比较复杂,需要专业设备支持,对主播的要求明显更高,通常需要一个固定的场地进行直播;2)RTMP需要云端转码,并且本地上传时也会在OBS中配置GOP和缓冲,延时相对较长。 6、高可用架构方案:云互备业务发展到一定阶段后,我们对于业务的稳定性也会有更高的要求,比如当云服务商服务出现问题时,我们没有备用方案就会出现业务一直等待服务商修复进度的问题。因此云互备方案就出现了:云互备指的是直播业务同时对接多家云服务商,当一家云服务商出现问题时,快速切换到其他服务商的服务节点,保证业务不受影响。 直播业务中经常遇到服务商的CDN节点下行速度较慢,或者是CDN节点存储的直播流有问题,此类问题有地域性,很难排查,因此目前做的互备云方案,主要是备份CDN节点。 目前蘑菇街整体的推流流程已经依赖了原有云平台的服务,因此我们通过在云直播后台中转推一路流到备份云平台上,备份云在接收到了直播流后会对流转码并且上传到备份云自身的CDN系统当中。一旦主平台CDN节点出现问题,我们可以将下发的拉流地址替换成备份云拉流地址,这样就可以保证业务快速修复并且观众无感知。 7、视频直播数据流解封装原理 介绍流协议之前,先要介绍我们从云端拿到一份数据,要经过几个步骤才能解析出最终需要的音视频数据。 另外:有关音视频编解码技术的文章,也可以详细学习以下文章: 视频编解码之:《理论概述》、《数字视频介绍》、《编码基础》、《预测技术介绍》《认识主流视频编码技术H.264》《如何开始音频编解码技术的学习》《音频基础及编码原理入门》《常见的实时语音通讯编码标准》《实时视频编码H.264的特点与优势》、《视频编码H.264、VP8的前世今生》《详解音频编解码的原理、演进和应用选型》、《零基础,史上最通俗视频编码技术入门》 8、视频直播传输协议1:HLS 首先介绍一下HLS协议。HLS是HTTP Live Streaming的简写,是由苹果公司提出的流媒体网络传输协议。 从名字可以明显看出:这一套协议是基于HTTP协议传输的。说到HLS协议:首先需要了解这一种协议是以视频切片的形式分段播放的,协议中使用的切片视频格式是TS,也就是我们前文提到的封装格式。在我们获取TS文件之前:协议首先要求请求一个M3U8格式的文件,M3U8是一个描述索引文件,它以一定的格式描述了TS地址的指向,我们根据M3U8文件中描述的内容,就可以获取每一段TS文件的CDN地址,通过加载TS地址分段播放就可以组合出一整段完整的视频。 HTTP-FLV协议,从名字上就可以明显看出是通过HTTP协议来传输FLV封装格式的一种协议。 FLV是Flash Video的简写,是一种文件体积小,适合在网络上传输的封包方式。FlV的视频编码格式通常是H.264,音频编码是ACC或MP3。 RTMP协议实际可以与HTTP-FLV协议归做同一种类型。 他们的封包格式都是FlV,但HTTP-FLV使用的传输协议是HTTP,RTMP拉流使用RTMP作为传输协议。RTMP是Adobe公司基于TCP做的一套实时消息传输协议,经常与Flash播放器匹配使用。 RTMP协议的优缺点非常明显。RTMP协议的优点主要是: 1)首先和HTTP-FLV一样,延迟比较低;2)其次它的稳定性非常好,适合长时间播放(由于播放时借用了Flash player强大的功能,即使开多路流同时播放也能保证页面不出现卡顿,很适合监控等场景)。但是Flash player目前在web端属于墙倒众人推的境地,主流浏览器渐渐都表示不再支持Flash player插件,在MAC上使用能够立刻将电脑变成烧烤用的铁板,资源消耗很大。在移动端H5基本属于完全不支持的状态,兼容性是它最大的问题。 11、视频直播传输协议4:MPEG-DASH MPEG-DASH这一协议属于新兴势力,和HLS一样,都是通过切片视频的方式进行播放。 他产生的背景是早期各大公司都自己搞自己的一套协议。比如苹果搞了HLS、微软搞了 MSS、Adobe还搞了HDS,这样使用者需要在多套协议封装的兼容问题上痛苦不堪。 于是大佬们凑到一起,将之前各个公司的流媒体协议方案做了一个整合,搞了一个新的协议。 由于同为切片视频播放的协议,DASH优劣势和HLS类似,可以支持切片之间多视频码率、多音轨的切换,比较适合点播业务,在直播中还是会有延时较长的问题。 视频直播协议选择非常关键的两点,在前文都已经有提到了,即低延时和更优的兼容性。首先从延时角度考虑:不考虑云端转码以及上下行的消耗,HLS和MPEG-DASH通过将切片时长减短,延时在10秒左右;RTMP和FLV理论上延时相当,在2-3秒。因此在延时方面HLS ≈ DASH > RTMP ≈ FLV。从兼容性角度考虑:HLS > FLV > RTMP,DASH由于一些项目历史原因,并且定位和HLS重复了,暂时没有对其兼容性做一个详尽的测试,被推出了选择的考虑范围。综上所述:我们可以通过动态判断环境的方式,选择当前环境下可用的最低延迟的协议。大致的策略就是优先使用HTTP-FLV,使用HLS作为兜底,在一些特殊需求场景下通过手动配置的方式切换为RTMP。对于HLS和HTTP-FLV:我们可以直接使用 hls.js 和 flv.js 做做解码播放,这两个库内部都是通过MSE做的解码。首先根据视频封装格式提取出对应的音视频chunk数据,在MediaSource中分别对音频和视频创建SourceBuffer,将音视频的编码数据喂给SourceBuffer后SourceBuffer内部会处理完剩下的解码和音视频对齐工作,最后MediaSource将Video标签中的src替换成MediaSource 对象进行播放。 在判断播放环境时我们可以参照 flv.js 内部的判断方式,通过调用MSE判断方法和模拟请求的方式判断MSE和StreamIO是否可用: 1 2 // 判断MediaSource是否被浏览器支持,H.264视频编码和Acc音频编码是否能够被支持解码 window.MediaSource && window.MediaSource.isTypeSupported( 'video/mp4; codecs="avc1.42E01E,mp4a.40.2"' );如果FLV播放不被支持的情况下:需要降级到HLS,这时候需要判断浏览器环境是否在移动端,移动端通常不需要 hls.js 通过MSE解码的方式进行播放,直接将M3U8的地址交给video的src即可。如果是PC端则判断MSE是否可用,如果可用就使用hls.js解码播放。 这些判读可以在自己的逻辑里提前判断后去拉取对应解码库的CDN,而不是等待三方库加载完成后使用三方库内部的方法判断,这样在选择解码库时就可以不把所有的库都拉下来,提高加载速度。 13、同层播放如何解决
[1] 移动端实时音视频直播技术详解(四):编码和封装 [2] 移动端实时音视频直播技术详解(五):推流和传输 [3] 实现延迟低于500毫秒的1080P实时音视频直播的实践分享 [4] 浅谈开发实时视频直播平台的技术要点 [5] 直播系统聊天技术(七):直播间海量聊天消息的架构设计难点实践 [6] 从0到1:万人在线的实时音视频直播技术实践分享(视频+PPT) [附件下载] [7] 实时视频编码H.264的特点与优势 [8] 视频编码H.264、VP8的前世今生 [9] 零基础,史上最通俗视频编码技术入门 [10] 视频编解码之编码基础 [11] 零基础入门:实时音视频技术基础知识全面盘点 [12] 实时音视频面视必备:快速掌握11个视频技术相关的基础概念 [13] 写给小白的实时音视频技术入门提纲 |
今日新闻 |
推荐新闻 |
CopyRight 2018-2019 办公设备维修网 版权所有 豫ICP备15022753号-3 |