文 / 朱明亮
整理 / LiveVideoStack
直播回放
大家好，我是来自YY的朱明亮。今天我将从以下几个方面，为大家介绍YY在舞台现场直播领域的技术实践。
1. 总体直播方案
1.1 背景介绍
每年，YY都会举办粉丝嘉年华活动，这是网络主播与粉丝线下见面的机会，很多主播会来到现场表演与互动；每年年末YY还会举办年度盛典，旨在表彰平台上一年内最优秀的网络主播，其中包括红毯与晚会等活动；除此之外，YY平台上一些高人气主播的高质量直播活动也需要我们强有力的技术支持，我们会允许主播使用相关直播方案，保证直播的质量及稳定性。
上图展示的就是年度盛典现场，复杂绚丽的舞美灯光音效对直播方案提出了更高的技术要求。
1.2 普通直播方案
为了保障规模巨大场景复杂的大型直播活动高质量进行，我们需要选择可靠高效的直播解决方案。对一些优先级与复杂程度一般的直播活动我们会选用较为普通的直播解决方案，前端采集画面数据的为普通摄像头或高清摄像机，采集到的数据通过采集卡输入至导播软件；除此之外，导播软件也可读取本地文件如片花或片头等以应对如直播刚开始时摄像头或高清摄像机无信号等突发情况，待采集端设备恢复正常工作后再将信号源切换到摄像头或高清摄像机；视频数据经过导播软件的编码推流等一系列处理流程后会被上传至YY平台，并通过YY的私有协议或RTMP协议进行分发，最终，用户可以通过PC、移动端与网页端等进行观看。
1.3 高可靠直播方案——双源双线路
如果面对的是如年度盛典与YY粉丝嘉年华等高规格高优先级的大型直播活动，我们需要高可靠直播方案为整场活动的顺利进行保驾护航。我们的思路是采用双源双线路的模式，前端采用多机位高清摄像机采集现场画面，多路视频数据接入现场的硬件导播台，导播台分出的一路HD SDI信号会先经过采集卡再到达软件导播并在软件导播处进行一系列音视频与画面处理，随后处理完成的数据经由编码与YY的私有协议推至YY云平台，这是上图展示的线路1；为了提升整个系统的可靠性，我们的直播频道采用多线路直播方案，一旦某个线路出现断路或推流失败，系统会自动将其他可用线路信号切换到该频道，从而保障直播的稳定；除此之外，每条线路还有备用直播方案，硬件导播台会继续分出一路HD SDI信号至硬件编码机并由此推流至平台，备用推流主要用于该线路主推流方案失效时确保直播过程的顺利进行；除了上述两条线路，我们还把由硬件导播台分出的第三路信号通过卫星发送并用卫星接收机在活动现场之外接收，此路信号会被传输至软件导播台，而后被推流至YY云中的同一频道，也就是上图展示的线路2；我们会为线路1与线路2选用不同的运营商，从而避免由运营商网络故障造成对直播活动的影响。双源双线路可有效提高直播活动的整体可靠性。
2. 软件导播台
这里着重介绍一下之前提到的软件导播台MShow。
2.1 MShow简介
MShow是一个PC端的编码推流软件，可实现信号切换、音视频处理、编码推流、提供高质量直播服务等，为YY的重大直播活动提供可靠技术保障。同样，MShow支持4K/H.265硬件编码直播与1080P/30fps/H.265软件编码直播。
2.2 MShow整体框架
MShow主要基于VideoSDK开发音视频处理功能包括编解码、采集、滤镜、渲染、推流等等；当被运用在YY平台时，MShow依赖YY的业务系统包括频道逻辑、开播逻辑、流管理、帐户体系等等；而被运用于第三方平台时则不依赖上述业务逻辑。
2.3 MShow音视频框架
音视频框架主要由视频与音频两部分组成。在视频部分，数据由包括采集卡、摄像头与文件组成的前端输入Video Source，并在随后的Video Filter进行滤镜处理，最后传输至编码器；音频部分的流程与视频类似，数据由麦克、声音回放系统或采集卡组成的前端输入Audio Source，进行后续的一系列处理。需要注意的是，上图展示的由Video Source指向Audio Source的虚线表示有的视频采集卡本身涵盖了音频信号，这些Video端收集到的音频信号可传输至音频处理部分与来自音频前端的数据一起进行编码等后续处理，这些处理完毕的码流会通过YY协议上传至平台，并进行封装与转码从而形成多码流。
3. 关键技术实践
3.1 音视频时戳处理
设计整个架构经历的关键技术实践值得我们探索，首先是音视频时戳处理。所谓时戳处理就是在切换不同视频源时进行的防止时戳突变或不同步的必要处理过程，有时一些片源其本身就包含了不规范的时戳，会出现突变或倒退，此时就需要我们主动对其进行修正。上图右侧展示的示意图中，蓝色横线表示整个直播流的一条时间轴，其保存的当前直播流的最大时间戳一直随着直播单调递增；当第一段视频结束之后，系统就会保存此视频的最大时戳，当然需对第一段视频的时戳进行变换，变换到系统时戳的时基；当切换到下一段视频时，如果下一段音视频的时戳不是从0开始，那么系统就会对此时间轴的时戳进行标准化处理，也就是将时戳最小规范到0，加上当前系统保存的最大时间戳再，最后将新时戳变换到其所在的音视频时间轴之上从而保证音视频切换平滑流畅。
3.2 视频滤镜处理
MShow会根据前端信号与所需编码推流的一些参数如宽高分辨率等形成特定的Filter字符串，并将其传递给avfilter graph alloc，再借助avfilter graph parse ptr解析此字符串，生成相应的Filter Graph；与此同时，MShow会将由采集卡获取的原始视频数据通过av buffersrc add frame传至BufferSrc，视频帧会经过FFmpeg Filter Graph的处理，处理完成后会通过av buffersink get frame被编码推流至MShow，完成视频滤镜的整个处理流程。
3.3 采集音视频预览
采集音视频预览主要在导播界面上进行。在采集卡接收到音频音效之后，操作者可能听不到声音，此时我们就需要对采集音视频进行预览。视频预览较为简单，主要过程就是接收到数据之后直接使用DX/OpenGL等渲染得到预览画面；音频预览则是在采集卡获取到原始音频数据之后使用SDL播放。如果音频数据并非来自采集卡而是来自系统回放设备则不需要预览播放，否则会出现回声现象。
4. 采集卡编程
采集卡编程主要分为两种常见类型：DirecShow采集与Decklink采集。前者多用于摄像头与Magewell，后者则多用于Blackmagic。
4.1 DirectShow采集
DirectShow采集流程如上图所示：首先，DirectShow会创建Filter Graph Manager，Filter Graph Manager则创建Graph，再创建一个可从采集卡上获取原始信号的Capture Filter并加入Graph，再创建Grabber Filter，加入Graph，并实现ISampleGrabber接口，可将采集到的原始数据传入MShow，由Mshow进行后续处理。
整体流程主要是，首先用户选择所需采集的设备，随后系统创建Filter Graph并枚举所有设备匹配用户所选；然后根据用户所选设备创建Capture Filter，同时加入Graph；接下来，系统会创建SampleGrabberCallback用来接收原始数据，根据用户需求设置视频格式并启动Graph。
4.2 Decklink采集
Decklink采集的流程如上图所示：首先MShow用户选择一个合适的Decklink Device，之后系统会创建一个Decklink Device Discovery实例，此实例会发现系统中的所有decklink设备并根据用户选择创建Device Instance，并从该设备查询获取一个IDecklink input Object；此Object会进行一系列实际操作如设置音视频数据回调、设置音频获取参数、采样率、声道数等等；接下来，系统会启用AudioInput与VideoInput，其中的VideoInput会根据用户选择的分辨率或帧率为其匹配一个最佳的模式并调用StartStreams，启动采集流程。一般情况下，根据输入设备不同，Decklink中只有一种格式是有效的，设置正确方可成功采集视频，不匹配则会出现黑屏；为了自动侦测采集卡视频格式，需要实现Format Changed通知函数；如果设置的格式与采集卡的格式不一致，就会触发Format Changed事件，在该函数里获取正确的视频参数，重新配置视频参数，并通知应用程序及时改变设置，比如MShow得到通知后需改变Filter Graph。调用SetCallBack，设置接收原始视频数据的回掉，采集到的原始视频数据由此回传至MShow。
在Decklink编程中我们需要注意以下几点：
1）Decklink一般仅支持两种颜色空间：8BitBGRA与8bitYUV。如果选择8BitBGRA那么其对应的FFmpeg中的颜色空间应为8BitBGR0而非8BitBGRA，否则画面就会出现混乱的现象。8bitYUV对应到FFmpeg里的YUYV422。
2）大部分设备使用Decklink仅有一种有效视频格式。启用EnableVideo时需要使用bmdVideoInputEnableFormatDetection用以自动侦测实际支持的格式并触发Format Change事件，需实现VideoInputFormatChanged，我们需要重置采集流程并重设视频参数；同时通知外部APP重置Filter Graph。
3）一般情况下摄像机输入的格式为Interlaced，此时我们需要在DShow上启用Deinterlace。
5. 稳定性与可靠性
为保证整个系统运行的稳定性与可靠性，我们做出了以下三个方面的实践与努力：在方案上我们采用了双线路推流与硬编备份的高可用方案，使得每条线路都有两条编码与推流，其中硬编作为备份；在硬件选择上我们选择高可靠性的采集卡与摄像机；在系统维护上我们实行日志机制与实时监控报警，多管齐下确保系统正常运行。
具体来说，我们在确保系统稳定可靠上做出的探索，主要包括机器性能、编解码错误事件、网络状况及传输性能三个方面数据的实时上报与码率自适应，相信这些探索能显著提升系统整体运行的安全稳定。
————————————————
版权声明：本文为CSDN博主「LiveVideoStack_」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/vn9PLgZvnPs1522s82g/article/details/85814606
「视频云技术」你最值得关注的音视频技术公众号，每周推送来自阿里云一线的实践技术文章，在这里与音视频领域一流工程师交流切磋。
