音视频客户端基础组件_音视频组件库-优快云博客

按照音视频的处理流程，音视频基础能力应该包括如下几个部分，检测、采集、处理、编码、存储、推流器、播放器（包括拉流），本文列出了音视频平台需要提供的基础能力，有的能力我们可以自己开发替代已有方案并逐步形成标准，有的能力技术门槛较高，考虑到投入人力较多以及开发周期较长，我们可集成第三方能力实现业务需求。

2、检测

2.1、机器性能检测

what

采集设备品牌、型号、CPU、内存等数据上报服务端，对机器进行打分，可分为高、中、低级别，作为评价机器性能的指标。

why

目前直播间、VR带看有实际的机器性能检测场景，设备性能达到一定的门槛，才能进行带看、直播。但目前的检测方案未成体系，可考虑作为基础能力沉淀下来。

how

客户端上报设备品牌、型号、CPU、内存等机器硬件信息以及应用场景，应用场景分为普通场景、IO密集型、CPU密集型三类。打分时普通场景CPU、内存权重占比各50%；IO密集型系统运行时大部分状况是CPU在等IO (硬盘/内存) 的读写操作，CPU负载并不高，因此该场景打分时内存权重占比要比CPU要高，比如CPU ：内存 = 40%：60%，这样即使一台设备的cpu核心数、主频很高，但IOPS较低的话，打分结果也可能不会高，满足不了IO密集型任务。CPU密集型场景打分方案设计同理。

who

涉及到Android、IOS、小程序、H5、服务端、QA，设备性能相关数据客户端RD相较于其他方向RD更熟悉，因此客户端同学主导推动、既是RD、又是PM。

2.2、麦克风、摄像头可用性检测

what

音视频采集前检测麦克风、摄像头是否可用。用户是否授予权限？麦克风、摄像头是否被占用？如果被占用，是哪个应用，能否检测的到？如果能检测到，如何合理提示用户杀死占用麦克风、摄像头的应用程序？

why

音视频采集前的必要阶段，录音、拍照、录制视频、刷脸等音视频采集场景很多，应作为独立组件沉淀下来。二手带看也有麦克风占用检测场景，探测麦克风是否能录取到有效声音，麦克风没有被占用的前提下，才能进入带看房间录制声音。link端视频会议入口，存在检测麦克风、摄像头、扬声器状态的应用场景。

how

客户端RD依据平台特性设计检测方案，目前麦克风探测器Android侧已经线上运行，摄像头占用检测使用的TRTC内部能力，IOS侧待确定。

who

客户端RD，客户端同学主导推动、既是RD、又是PM。

2.3、网络环境检测

what

网络请求前进行网络测速，判定当前是否是弱网环境。

why

直播、视频会议等场景在进入房间前、直播中/会议中需要进行网络测速，进房前网络环境较差的话可禁止进房，直播中/会议中网络环境较差的话可进行UI提示解释音视频通话效果差的原因。目前直播间的网络检测能力依赖于TRTC，音视频平台可考虑搭建网络环境检测组件。

how

先判断网络类型，GPRS、WIFI、宽带，GPRS 3G网络直接判定为弱网，其他类型才进行测速，网络测速指标包括：上/下行带宽(kbps)、上/下行丢包率、网络延迟rtt（一次网络请求的往返时间），综合上述三项指标计算网络质量，作为衡量网络环境的标准。

who

客户端RD、小程序、H5、服务端。

3、采集

3.1、音频（麦克风）

what

采集音频（pcm）。

why

音频采集使用场景很多，如大班会ASR、小贝训练场、IM语音消息、IM语音识别，仅需要采集音频而集成腾讯云TRTC的话显然不是合适的方案，因此直播中台需要提供单独的音频采集能力。

how

客户端RD依据平台特性设计方案，包括采集音频、分贝计算、存储、重采样、wav与pcm互转，目前Android侧的录音组件已经上线运行，IOS侧应该是还没有（不对请批评指正）。

who

客户端RD。

3.2、视频（摄像头）

what

采集视频（yuv）。

why

单独的视频采集在目前的业务中尚未发现使用场景（存疑，请指正），但经济人/客户都有录制视频、拍照场景，仅需要采集音频而集成腾讯云TRTC的话显然不是合适的方案，因此直播中台需要提供单独的视频采集能力。

how

客户端RD依据平台特性设计方案，目前两端都没有独立的视频采集能力。

who

客户端RD。

3.3、录屏（屏幕）

what

录制屏幕内容，实时上传服务端或者本地保存成视频文件。

why

录屏场景还是很多的，经纪人给用户介绍房源、贷款资料需要录屏，必行已经用到。经纪人/客户都有需要记录屏幕上的操作的场景。产研中也需要录屏，RD找经纪人/用户复现问题，需要录屏找到复现路径；QA复现bug也需要录屏。

目前中台的录屏能力是TRTC提供的，TRTC业务过重，只需要录屏而集成TRTC的话不是合适的方案，并且TRTC的录屏方案也不成熟，必行对接过程中发现腾讯的录屏有很多问题，目前Android侧已经开发了录屏组件，IOS侧方阔也调研了录屏方案，录屏应作为直播中台的一项基础能力。

how

客户端RD依据平台特性设计方案。

who

客户端RD主导推动。

4、处理

4.1、音频

音频处理链路：

what

音频采集后编码前需要经过预处理阶段，AGC控制音频输出功率，使输出信号振幅保持恒定，ASR/TTS场景有助于提高识别准确率，播放音频场景可避免用户频繁的调整播放音量从而提高用户体验，因此直播中台有必要提供AGC能力；AEC可实现音源信号剥离，只保留近端信号消除不必要的远端信号，由于人耳的遮蔽效应，强信号会遮蔽邻近频率的弱信号，因此播放场景时AEC发挥的作用很有限，实际意义不大，ASR/TTS场景也一样对于提供识别准确率帮助不大，因此可暂不考虑AEC。大部分麦克风阵列已经提供了降噪能力，软件层面也可继续提供降噪能力，目前不是当务之急，可暂不考虑。vad可检测音频帧的活性从而进行有效截断，可节省流量，能量vad可满足基本需求，算法封装较简单，可先构建能量vad组件，模型vad需要大量的音频数据训练声学模型，我们没有条件，目前AIT搭建了vad插件，可一起共建。

why

音频处理，提升用户体验、节省流量。

how

agc可参考webrtc中agc部分中自适应数字增益（AdaptiveDigital）算法模块进行封装；vad也可参考webrtc中的能量vad部分，后期如果需要过滤噪音、静白音可考虑将声学模型部署在本地。

who

客户端RD。

4.1.1、AGC

自动增益控制的主要作用是，当功放的输入信号幅度变化很大的情况下，使输出信号幅度保持恒定。当输入信号达到一定强度时，启动压缩功能，减小放大增益，使得输出幅度降低；当输入信号降低到一定程度时，再逐渐恢复默认的放大增益。AGC能够保证输入信号的幅度在不断变化，但是输出信号的幅度是固定的，也就是说输出功率是固定的。这样可避免用户频繁的调整播放音量以及戴耳机的用户承受着大音量对耳朵的 “暴击”的情况发生。

可参考webrtc中agc部分中自适应数字增益（AdaptiveDigital）算法模块进行封装。

4.1.2、AEC

回声消除本质上更像是音源分离，我们期望从混合的近端信号中消除不需要的远端信号，保留近端人声发送到远端，webrtc中也有方案可参考。实际应用场景不多，建议先不考虑。

4.1.3、ANS

webrtc中也有方案可参考，建议先不考虑。

4.1.4、VAD

实时音频处理场景VAD是必须的，节省流量，能量vad可满足基本需求，算法封装较简单，webrtc中也有参考，可先构建能量vad组件，模型vad需要大量的音频数据进行训练，我们没有条件。目前AIT搭建了vad插件，可一起共建。

4.2、视频

what

视频剪辑，分割成的若干段可进行删除、替换、添加。视频编辑实现翻转、裁剪、加图片、加文字；轨道处理可实现音频、视频流提取，替换/添加音轨；格式转换可实现音频、视频编码格式转换以及容器格式转换。

why

目前在实际业务中没有发现视频处理场景（存疑，请指正），优先级不高。

how

如果需要视频处理能力的话，三种方案，TRTC短视频接口/FFmpeg/硬编码。

who

直播中台客户端RD、人工智能中心RD

4.2.1、剪辑

视频分割，分割成的若干段可进行删除、替换、添加（视频、图片），FFmpeg或硬编方案。

4.2.2、编辑

翻转、裁剪、加图片、加文字，FFmpeg或硬编方案。

4.2.3、轨道处理

音频、视频流提取，替换/添加音轨，FFmpeg或硬编方案。

4.2.4、格式转换

音频、视频编码格式转换；容器格式转换，FFmpeg方案

4.2.5、美颜、滤镜

美颜是针对人像进行处理，可以有效的提高人脸的一些识别性以及人脸的完美性，包括美白、磨皮、祛斑、面部重塑（瘦脸、大眼、隆鼻）等操作。

滤镜改变图片的色调，可以将不同色调的图片统一为同一个色调。

MediaCodec+MediaExtractor+MediaMuxer硬编方案不支持，FFmpeg不支持，需要集成旷视、火山引擎等第三方美颜SDK或者集成OpenCV做图像处理以及OpenGL做图像渲染。

5、编码

what

音频、视频编码，音频pcm ↔aac、opus、speex、mp3，视频 yuv <->h.264、h.265。

why

在保证音质、画质的前提下，最大限度的去冗余、提高压缩率，降低流量消耗，降低带宽负担。

how

音频编码opus、speex开源方案；视频编码采用FFmpeg软编或者硬编码。

who

客户端RD

5.1、音频

音频编码主要是为了降低流量消耗，降低带宽负担，同时音视频场景可以为视频腾出更多带宽空间。两种开源方案，speex(基本已经弃用)，opus(瑞士军刀，如日中天)，采样率、声道数、复杂度等参数集成方动态传入即可，服务端解码参数需要与编码参数要一致。FFmpeg目前支持的音频编码标准包括，AAC、opus、speex、mp3等。

5.2、视频

FFmpeg或硬编方案，FFmpeg目前支持的视频编码标准包括，H.264(AVC) 、H.265(HEVC)等。

6、推流器

从音视频采集到推流的流程如下：

what

实时编码、推流；读取文件推流。

why

未发现实际使用场景（存疑，请指正）

how

FFmpeg中librtmp推流，或者根据具体网络协议进行推流。

who

客户端RD、服务端。

7、播放器

从拉流到播放的过程如下：

what

音频播放器+音视频播放器

why

小贝训练、贝壳经纪学堂-课程讲解、音频专栏，存在音频、视频播放场景，直播中台有必要提供一款简易的音频、视频播放器。

how

系统API、ijkplayer、FFmpeg

who

客户端RD。

8、白板

what

提供白板可进行涂鸦（绘制图形、画笔、文本）、橡皮擦、加载图片、加载H5、远端数据同步、白板页管理（缩放、翻页、增加、删除）、音视频播放、背景管理（添加、删除）、白板内容与音视频同步

why

初衷是要替换腾讯的白板方案，目前来看无法脱离腾讯白板，白板本地操作（包括涂鸦、加载图片、h5、音视频播放、背景）客户端可以实现，但TRTC的音视频和白板是同步录制的，替换白板无法实现与TRTC的同步录制。单独提供的白板的能力必要也不大，因为白板作用主要用于在线教学场景，必然要和音视频结合在一起使用，单独使用白板的场景很少，目前也没发现单独使用白板的场景（请指正）。

how

view绘制

who

客户端RD