有好多次视频社交行业的开发者提到，某厂商的视频交友SDK测试的时候性能效果还可以，可是接入过程中和接入后就遇到各种各样的坑： 1）无法自行定制采集和渲染。 2）无法获得原始语音视频数据，进行保存、前处理和编码等定制化操作。 因此，视频交友SDK的开

　　有好多次视频社交行业的开发者提到，某厂商的视频交友SDK测试的时候性能效果还可以，可是接入过程中和接入后就遇到各种各样的坑：

　　1）无法自行定制采集和渲染。

　　2）无法获得原始语音视频数据，进行保存、前处理和编码等定制化操作。

　　因此，视频交友SDK的开发策略也要重点考量。

　　数据流动

　　视频交友SDK选择在数据流动的各个环节开放接口。语音视频实时通讯本质上是语音视频数据的实时流动，数据流通的各个重要环节如下：

　　上图展示了语音视频数据从推流端流动到拉流端的各个环节：采集（包含语音3A前处理）、前处理、编码、推流、拉流、解码和渲染。

　　视频交友SDK以上就是开发者负责的业务层，这七大环节都是在视频交友SDK以下实现的。这七大环节都是被视频交友SDK封装好的。完全封装的好处是一方面可以让开发者专注业务层的逻辑，另一方面让业务层和SDK完全解耦。不足是开发者一定程度上失去了对底层语音视频数据的控制力。

　　有些视频社交SDK厂商向开发者开放部分接口，也有厂商完全不开放任何接口。每一家视频社交SDK厂商的开放策略都不一样。使用视频社交SDK的开放接口能获得多少对底层语音视频数据的控制力呢？

　　今天让我们讨论一下视频交友SDK的开放策略。

　　采集

　　采集端是语音视频数据的来源，包括但不限于硬件设备（麦克风和摄像头）、屏幕共享、语音视频文件播放和游戏直播画面等。

　　如果采集端是硬件设备，那么视频社交SDK可以驱动麦克风和摄像头来获得语音视频数据。如果采集端不是硬件设备，那么开发者要采用外部采集的方式让SDK获得语音视频数据。

　　一般来说，有三种场景是需要进行外部采集的：

　　1）普通的硬件设备无法满足业务需求，开发者已采用特殊的硬件设备来实现了大量业务。

　　2）开发者需要使用摄像头完成额外的功能，和视频社交SDK 的默认逻辑产生冲突，导致摄像头无法正常使用。比如说，在视频通话过程中，业务层要求中断通话，用摄像头来录制短视频。

　　3）语音视频数据并非来自摄像头和麦克风，而是来自虚拟设备、语音视频文件或者现有的语音视频流。比如说，语音视频文件播放、屏幕分享和游戏直播等。

　　在需要进行外部采集的场景中，视频社交SDK要开放采集环节的接口来支持。否则，开发者就只能从摄像头和麦克风等硬件设备直接获取语音视频数据，业务开发就会面临极大的局限性。

　　视频社交SDK开放了采集环节的接口，允许开发者进行外部采集，开发者的自由度和掌控力一下子海阔天空。

　　然而凡事都有两面：语音3A前处理是在采集环节完成的，因此，如果进行外部采集，开发者就要自行实现语音3A前处理。语音3A前处理包含回声消除（AEC）,噪声抑制（ANS）和自动增益控制（AGC）,也就是所谓的语音3A，是视频社交行业公认的技术难题。

　　前处理

　　前处理是指对语音视频原始数据在编码之前进行的处理，包括语音3A和其它特殊的效果。语音3A是在采集环节完成的，除此以外还有其它的语音和视频的前处理，将在本环节完成。

　　语音前处理是编码前的语音特效处理，包括混响和变声等。混响能让声音听起来像来自旷野，变声能让人声由男生变女生，或者产生电子声特效，以此增强语音通话的趣味。

　　视频前处理是编码前的视频特效处理，包括美颜、萌颜、挂件和滤镜效果等，能让画面显得妙趣横生，以此增强视频社交的乐趣。

　　如果视频社交SDK开放了前处理的接口，那么开发者可以自行实现语音和视频的前处理模块，或者对接第三方的语音和视频的前处理SDK。否则，对开发者来说，视频社交SDK以下的语音视频处理都是黑盒子，业务层无法对其做任何控制。

　　笔者在即构科技获得的数据表明，美颜和萌颜有着广泛的市场需求，这两个模块是视频社交SDK的标配。另外，市场上有一些优质的第三方美颜SDK，视频社交SDK应该开放前处理的接口，让开发者自由选择是采用视频SDK自带的美颜功能，还是自行实现，或者对接第三方厂商的美颜SDK。只有这样，开发者才真正拥有自由度和掌控力，进行积极的业务创新。

　　编码

　　编码这个环节留给开发者的余地不多：开发者基本不会自行开发或者改造编解码器。然而，一些有经验的开发团队仍然有自行编码的需求，原因有如下两个：

　　1）开发者对调制编码器的参数来适配种类繁多的安卓机型十分有经验和信心，决定自行编码。开发者可以自行灵活地配置编码器的参数，从而达到更好地适配各种安卓机型的效果。

　　2）开发者之前已经实现了大量调用编码器的逻辑，而且相信自行编码的效果更好。为了保护已有投资，开发者往往倾向于自行编码。

　　需要特别注意的是，开发者自行编码这种做法有得也有失：好处是开发者获得了更大的掌控力和自由度；坏处是视频社交SDK将无法为开发者提供码率自适应的功能。

　　如果要理解背后的原因，让我们先了解码率自适应的原理：视频社交SDK实时监控网络状况，使用算法预测网络状况的变化，然后根据预测结果动态调整编码器的参数，编出和网络状况相适应的码流。编出来的码流的码率、分辨率、帧速等参数能让实时通讯在当时的网络情况下保障良好的QoS。

　　如果视频交友SDK负责编码，那么它就能实现码率自适应功能。如果开发者负责编码，那么视频交友SDK就无法控制编码器来编出适应网络状况变化的码流，因此无法做到码率自适应。

　　网络传输

　　网络传输环节是实时通讯的核心中的核心，通过FEC、ARQ、流控码控和抖动缓冲等关键算法来实现实时传输架构，从而达到超低延迟的效果。

　　根据笔者的了解，还没有厂商全面开放网络传输环节。即构科技的做法是：支持开发者自行推流到即构的服务器，然而拉流端拉流的时候必须要使用即构的视频社交SDK。这样既可以保持了SDK的开放性，兼容开发者原有的系统，又可以保障拉流端获得低延迟的体验。

　　这种做法背后的逻辑比较好理解：视频交友SDK的核心价值是实时性，延迟超低。因为厂商在实现超低延迟上有专长，所以开发者才采用厂商的视频交友SDK。如果厂商把这个核心环节开放给开发者自行实现，那么厂商就失去了它的核心价值。

　　解码

　　解码环节和编码环节相对应，把接收到的语音视频流解码然后渲染。解码环节没有什么可以供开发者发挥的余地。开发者一般没有自行解码的需求，厂商一般也没有开放解码环节的接口。

　　渲染