基于安卓的超高清视频导播系统的设计与实现

关键词：带货直播 超高清 音视频 低延时 导播

第一章 前言

1.1研究背景

目前火爆全网的带货直播激发了用户对音视频体验的要求越来越高，音视频体验整体表现为超高质量、超高流畅度、极低时延、低成本。超高质量：分辨率要求从2K、4K到8K、12K，观看沉浸式体验要求也从2D、3D到VR、AR;帧率也从30帧、60帧向120FPS迈进。超高流畅度：从无卡顿到不高于百分之三的丢包重传率;极低时延：从主播和观众实时交互到不高于50ms的极低时延;低成本：音视频技术的飞速发展降低了行业门槛，流量、算力及存储消耗因为硬件成本的降低导致总价越来越亲民。高效便捷的直播导播系统或设备逐渐像手机一样进入更多人的生活和工作之中。

1.2研究意义

2019年底爆发的新冠疫情持续至今并没有结束的迹象，疫情促生的隔离经济加速了直播行业的发展：如带货直播、视频会议、远程教育、企业在线培训等，直播已成很多人在生活、工作中重要的工具，也成为企业和个人适应调整当前疫情经济下的友好支撑。直播的实时性和连麦互动带来的强烈的互动感、现场感促进了人与人之间的连接关系，科技与生俱来的优势也成为直播带货得以风靡全网的重要原因。

传统的导播台不仅需要切换台，还需要调音台、录机、电脑等大型硬件设备，携带非常不方便，加上硬件设备叠加的成本很高，一般的个人或者企业只能望而却步。这類设备一般是通过工控主板，接入USB摄像头的方式实现的，除了设备专业复杂、价格非常昂贵等弊端外，也很难实现画面特效、虚拟场景等各种视频实时编辑功能，亦无法满足当前灵活多变的市场需求。如果能够开发出一套专业便捷的直播导播系统，通过植入到一台设备中就可以实现全部的功能：视频编辑导播在本地，视频实时存储在云端，用户只需要一台手机就可以在线观看。不但省去视频后期剪辑的大量工作而且节约了软硬件的直接成本，很大程度上改善了用户体验，是非常值得深入研究并实现的。

第二章 平台需求

2.1 硬件平台

●高通骁龙八核处理器;

●多路HDMI输入，全高清4K+分辨率;

●多网络聚合;

●多类型接口HDMI、USB、网络;

2.2 软件平台

●安卓9.0

●多机位1080P导播切换;

●高性能H264/H265视频编解码;

●连麦视频会议模块;

●4G/5G网络自由选择;

●多音频混合输入;

●视频输入自由编辑功能：机位切换、画中画、绿幕抠图、水印、换背景图等;

●支持多平台推流、三方平台无推流、地址推流;

●超高清视频的本地及云端存储;

第三章 设计实现

设备的CPU使用高通骁龙八核处理器kyro架构，属于在智能终端上的最高性能方案之一。设备的操作系统采用普遍使用的安卓操作系统，稳定易用性高。在输入/输出接口方面，采用扩展HDMI USB 输入接口，支持超高清4K视频输入;以两路HDMI 输入、两路USB 1080P输入、两路网络输入、一路本地输入，实现七路不同机位和设备的实时输入为例，同时支持声音混流，加嵌、解嵌等。

本地视频存储采用SSD的固态硬盘存储方案，网络流和图片库提供云端地址接口支持云端存储。推流地址的获取支持直接扫码自动填写。

3.1 快速切换设计原理及方法

快速切换是指不同机位或者是网络流和背景之间的切换，从当前正在推流的画面快速切换到备用预览的其他画面。当用户切换画面的时希望导播系统能实时无缝的切换到期望的画面，然后推流到服务器端，用户看到的画面和导播用户看到的画面需要保持一致。为避免出现画面黑屏、叠影、中断等异常情况，需要在整个链路上进行优化，而快速切换设计在用户体验中发挥很关键的作用。

为达到以上目的，HDMI及网络、USB摄像头等多路流切换前后始终保持编解码不断开，开启预览后所有的视频流都一直处于解码状态。当推流发生切换，编码器立即更换编码流id，继续编码推流，并且发送新的视频头部信息。通过提前准备好数据流来实现多机位视频的无缝切换，而切换之后发送新一路流的视频头部信息可以避免切换延迟。当发现新的数据流会清掉前面部分的数据，立即切换到新的数据流。通过以上方法实现了视频快速无缝切换并推流的目的。

3.2 低延时设计原理和方法

低延时主要包括两个部分：直播低延时和连麦互动低延时。

直播延时的原因分析及低延时设计

首先是启动过程产生的延时分析，导播编码系统在对不同机位的流进行切换和组合时需要进行协议转换和编解码。如果切换的时候才开始获取数据流并进行编解码，再去拉取流进行处理，就会增加切换触发过程和启动过程耗时。针对该问题，该导播平台针对所有输入在全链路上进行预热，提前启动协议转换、媒体编解码和解封装的处理任务，预监和推流同时并行运行，即使关闭推流功能，各个预览画面的编解码任务也会一直运行工作，这样在重新打开推流功能时能立即取到内容并推流到服务器端。

其次链路缓存是整条直播链路产生延时的主要原因。为尽可能避免缓存延时，提前缓存数据是优化网络抖动比较有效的方法，链路缓存存在输入流的输出端，编解码器内部和数据传输的网络层。导播系统需要在导播切换的时候丢弃掉之前缓存的大部分备用数据，而选择最接近当前时间的关键帧开始发送数据，在编解码内部，采用合理的编解码参数调节以及随时最大限度的主动推流的方式降低编解码产生的延时。链路选择上，采用最近的节点就近传输，然后再通过服务器FORWARD到对应的节点，用户端也可以就近选择拉流观看。

另外，播放器缓存也是延迟优化很关键的部分。大多数播放器会缓存解码一部分的视频数据第一帧画面才开始展示，这样能够防止因为链路抖动而使得画面观看起来更流畅，通常来说播放器缓存引起的延时占据了整体延时的60%。所以播放器主要是从缓存和解码效率两个方面降低延迟。

互动连麦低延时设计

针对连麦等实时性要求极高的互动就需要使用比如WEBRTC等更实时的播放协议，可以将延时进一步调整到100ms以内。所以一般连麦互动和视频传输分开，连麦采用超低延时的WEBRTC协议，不超过100ms的延迟让互动身临其境;文字和视频传输采用比较稳定的RTMP协议，降低网络抖动引起的信息损耗，而视频传输还能更具用户的网络环境选择适合自己的最佳线路，从而为每个观看者带来最佳的视听体验。

3.3 多平台推流

“一播多用”是为了直播可以在各个平台同时发布和播放，不但支持在不同平台的用户同时观看，更减少了视频后期分发的工作。只要事先设置好推流参数，就可以实时推流到抖音、快手、B站、虎牙等平台。如果有的平台需要加上自己的水印才可以推流，就需要在客户端选择水印图片叠加之后再推流。多平台推流可以直接通过客户端实现两份数据的复制推流，也可以通过云端实现转推。

客户端嵌入式推流的实现硬件都只需要做一次解码，只需要推流部分实现流的复制和转推。硬件平台直接推流到多个平台，需要消耗客户端的性能，但是也分散了服务器端的压力。而且能够实现各个平台延迟最小。

服务器云端实现多平臺推流，是通过服务器软件来实现将流FORWORD到各个平台。这种多平台推流实际是通过平台转发来实现的。主要消耗服务器的计算资源，针对Intel系列的V3以下的CPU，一路直播流编解码基本上需要消耗一个逻辑核资源。

3.4 无需推流地址推流

鉴于各大平台对自身服务器端的保护机制，推流地址的获取越来越复杂，对于普通的用户来说无疑是增加了难度。为了减少推流的难度，导播设备可以结合第三方平台实现一套完整的无推流地址的解决方案。

具体实现方法重载系统底层camera回调函数，自研客户端实现HDMI和USB已经网络流的切换并实现画面编辑，并在启动抖音等第三方客户端的同时系统会自动启动自研的客户端。导播系统自有客户端在实现本地流的切换和组合及编辑之后可以随时收起成一个小图标，处理完的数据流会倒回camera，然后抖音等第三方服务平台再从camera获取到数据流，最终推流到抖音等第三方的服务器端。这样三方服务平台客户端这里所有的流程都不做改变，但是实际拿到的流是经过处理和导播的视频流。这样就完美解决了第三方服务器端地址无法获取或者减少地址获取的工作量。为非专业人员的直播推流减少了难度，节省了时间。真正实现一键直播和推流。这种方式适用其他所有的三方服务平台客户端，不需要一一定制。

第四章 主要问题及分析

4.1底层功能

1）安卓手机默认的系统架构并不是完全适配HDMI的，比如在热拔插、帧率选择等特殊问题需要大量改动。原先摄像头架构体系和代码太庞大也会增加更改难度。

2）本方案中HDMI输入芯片选用TC358840，由于市场上资料比较少，必须依靠供应商提供资料，其提供的资料有任何问题，就会影响导播系统的效果。任何产品都有自身的缺陷，包括在调840驱动时，也有遇到写入大小端不一致、寄存器写入不起作用、芯片识别到后数据流异常等问题。

3）芯片跟硬件联调，也存在抗干扰问题，导致HDMI在热拔插的时候容易死机。音频输入方面也有碰到芯片电压不匹配等问题，造成软件开发难度加大。后续还需要解决的问题有：外部信号输入需要动态调节，比如同一个信号输入源分辨率、帧率的改变，设备能实现自适应调节。

4.2性能瓶颈

客户端性能瓶颈

导播设备包含两路HDMI高清输入、一路USB本地输入、三路网络流输入、一路本地视频流输入预览，同时还支持本地更换图片背景。如果同时打开预览窗和推流窗，就会消耗非常多的计算资源。从源端获取到camera的数据流并解码，然后调用底层encoder封装转码为目标格式，然后以高清码率和高帧率推流到服务器端。由于编解码和转封装非常消耗CPU，同时开启多路预览的时候CPU资源会成为瓶颈，这就需要通过业务和性能优化多种思路来解决这个问题。

其中业务端方面可以通过预览窗口不获取所有的数据帧，即抽帧的方式来减少CPU的消耗，既预览窗口只需要每秒10帧以下的播放速度展示。一旦切换到当前窗口推流，客户端立即向底层发起请求，底层立即以正常的帧率60帧每秒的速度从camera获取数据并通过客户端推流到服务器端。只要保持当前推流的窗口是正常帧率就不影响业务使用，预览窗口通过抽帧的方式则极大降低了资源的消耗。

另一方面，通过优化安卓系统的底层进程和线程个数来减少不必要的资源消耗，尽可能降低资源利用。还可以通过硬编码的方式来减少软件带来的计算资源压力。此外，对于循环播放的网络流可以通过本地加载若干数据，来减少从网络获取数据的压力。不但减少了带宽资源也减少了cpu的压力。

服务器性能瓶颈

服务器收到推流请求，接受并存储rtmp协议的流，支持同时存储为多个码率存储，包括超高清、高清和标清模式。这些码率需要通过服务器端实时转码存储，消耗大量的CPU资源。

服务器端性能的优化主要通过协议栈性能调优的方式来降低资源消耗，比如增加MTU的大小来减少数据传输的频率，从而降低CPU的消耗。数据采用分布式存储，降低IO吞吐带来的压力，从而降低资源的消耗。

4.3稳定性

与传统硬件导播台相比，传统的导播设备定制硬件、专线网络、固定格式的流媒体输入;而本系统是基于安卓平台开发的导播系统，它使用通用硬件平台，网络环境和设备环境也是复杂多变，意外和突发事件概率加大，稳定性上面临着更大挑战。为了提升稳定性，直播导播系统需要在应用层和服务器端实现实时异常检测和故障调度，有效应对单点故障等异常，同时提供预览导播、快速切换、紧急网络垫片流等多项应急功能也是解决稳定性的有效选择。云端服务器则通过主备集群、备份默认节点、服务过载自启动新的节点等方式来提高业务的稳定性。

4.4三方服务平台限制瓶颈

为了避免服务器资源的浪费和绕过第三方平台构建的商业壁垒，三方平台的服务器端逐渐关闭了推流地址的自由获取，专业设备的直播地址获取变得越来越复杂。初期已经实现的推流地址填写并推流的功能已经在很多平台失效。安卓系统的开源为解决这一问题带来了便利，通过重载和模拟camera的行为，新增并扩展了手机的前后置摄像头，并虚拟出类camera的属性。原始的前后置摄像头可以被扩展为多路HDMI的输入，而类camera则可以实现模拟原始摄像头的能力，从而修改了三方平台的原始数据流。实现视频数据流的编解码和编辑功能，从而完美解决了推流地址获取的问题。

综上，该功能是利用了三方视频平台对安卓操作系统的兼容性实现了不需要获取推流地址就可以推专业设备的视频流到三方服务器平台。

第五章 性能结果和使用场景

5.1设备性能

客户端设备能同时支持一路60帧4K、一路30帧1080P、三路网络视频流、一路本地视频流、一路图片切换。在网络环境良好的条件下，支持以上各路视频无缝切换导播，并实时画中画叠加推流、同时推流到3个以上平台。画质清晰流畅，无卡顿花屏等异常问题，满足了客户端设备性能的各类要求。

5.2使用场景

该视频导播系统可以在游戏、教育，会议、电商直播、婚礼活动等场景中，进行画面导播和视频编辑。此类场景主要通过视频推流直播结合视频的内容分发网络，实现在全国各地都可以就近获取到最近的流媒体视频，从而获取最佳的用户体验。

此外，该系统也可以用于圆桌会议、连麦等场景，支持少数人的在线实时互通，和多数人的在线直播观看。连麦需要视频整个链路延迟100ms以内，保证人的视听基本感受不到网络带来的延迟感。而多数人的在线观看可以支持延迟1-5s内，视频直播再叠加上文字互动。从而达到相对优质的用户体验。

第六章 局限性

本设备存在的局限性主要是和外部环境的变化有关系。

一方面是性能瓶颈的局限性：该导播平台使用安卓9.0系统，目前的手机硬件平台就成为设备的一大局限，因此无法从性能上超越目前主流手机的主芯片性能。

另一方面，由于第三方平台的服务器会做各种限制，比如推流码率、帧率等的限制，无法彻底摆脱三方视频平台的制约。视频质量也因此存在一定程度的局限性。如果设备推过高码率和帧率的视频会被三方视频平台检测到并被拒绝，或者特别异常的提醒信息影响用户体验。另外，有些视频平台必须有本平台水印才被认为是合法内容，三方平台的改变也会需要设备跟随着改变，这也增加了设备的维护和升级频率。

第七章 结语

总之，与传统导播台相比，本导播平台拥有低成本、方便快捷、支持弹性扩展、多协议兼容、场景丰富等多项优势，适用于多视角直播、跨城同屏直播、在线教育、直播带货等多种场景。该导播系统方便易用，只需要一台内置本系统的集成设备及摄像头就可以实现不同场景的一键导播直播需求。

第八章 附录

[1]陈戈.智能导播助力2021春晚新媒体节目创新——浅析人工智能切换技术的应用[J].现代电视技术，2021（03）：35-40.

[2]张韵.浅析综艺演播室新闻虚拟制作音频技术方案[J].现代电视技术，2021（10）：139-142.

[3]吴天亭. H.264视频软导播系统的设计与实现[D].成都信息工程学院，2013.

[4]郑堃，刘强，殷茂森.全媒体互动直播的探索与实践[J].演艺科技，2020（05）：58-63.

[5]方霁，郑倩，王一梅，马特.关于云导播台交互方式的探讨[J].广播电视信息，2021，28（08）：22-25.DOI：10.16045/j.cnki.rti.2021.08.002.

作者简介：邹世明：女，汉族，广东深圳。 中国人民大学计算机应用专業