目录
1、背景
按照音视频的处理流程，音视频基础能力应该包括如下几个部分，检测、采集、处理、编码、存储、推流器、播放器（包括拉流），本文列出了音视频平台需要提供的基础能力，有的能力我们可以自己开发替代已有方案并逐步形成标准，有的能力技术门槛较高，考虑到投入人力较多以及开发周期较长，我们可集成第三方能力实现业务需求。
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。
最低0.47元/天 解锁文章
1452
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
