音视频大佬离职后，我是如何在短时间内在音视频开发做出一个性价比高的最优方案

今年年初因为公司组织架构调整，我从原先半需求半音视频的业务单位部门，迁移到专职音视频开发工作的公共部门。该次架构的调整让自己能够全身心的投入到基础音视频的开发，疑难问题攻坚，新功能设计和开发，新方案预研和落地的全职音质视频工作中来，能够发挥自己的特长和专业性，能够满足兴趣和工作完美结合，特别是视频的开发工作。

就在沉浸于这份快乐和喜悦时，一个晴天霹雳把自己炸回到现实中。部门一个音频大佬趁着金三银四找了下家要离职，而自己作为补位选手要承担这位大佬的坑位，真正做到音视频全职投入了。

接到的第一个任务就是设计一套语音呼叫与研发方案。“春风骋巧如剪刀，先裁杨柳后杏桃”，在音视频领域，构建基本的音视频能力仅仅是万里长征走完第一步，而现在基础服务的覆盖率已经有了长足进步，仅仅能够支持基础功能，已经无法满足客户的需求，在 RTC 市场上，基本上没有办法守得一城一池，更不要说攻城略地了。所以自己面临的压力也是非常大的，最初自己是拒绝的，毕竟这个差事出力不讨好，不像视频方向自己可以得心应手。然而反过来思索下，如果自己承担这块内容，之后再跳槽岂不是更加容易？小算盘打的啪啪响。

冷静下来分析一下，自己面临的压力主要是以下几个：

（1）在大佬离职之后，自己如何快速承担其他的工作内容？

（2）如何进一步提升公司的音视频竞争力？

（3）如何构建坚固的护城河？

自己和部门经理也一起商讨方案，找出一个最快，最优的方案，一方面不耽误业务部门的正常需求开发，同时让自己有足够时间完成该部分的积累。

（1）先逐步学习大佬的笔记，交接文档，能够基本具有开发音频的能力；并以最快速度上手完成这个语音呼叫方案的搭建，以及部署；

（2）调研市面上的 SDK 厂商，看看是否可以直接导入，由于是新品可以不依赖大佬的设计，而采用外部第三方的集成方案，达到最优效果，备选方案，作为托底方案；

（3）结合自研算法和第三方 SDK 逐步完成公司语音呼叫的整体框架重构，然后慢慢移除第三方 SDK，搭建自己的 SDK，这个是长期目标，徐徐图之；

当然学习大佬的笔记和文档的过程是痛苦的，毕竟音频中很多内容和处理方式和视频还是有很大差距的，中间因为一些概念理解不足，走了一段弯路。比如采样周期和采样大小的设置不同，会导致自研算法的收敛性极其不稳定。但是这里有了一个积累过程还是慢慢承担了一点业务部门的需求，能够基本承担了该部分的开发。而且 WebRTC 中很多算法虽然开源，但是真正落地起来还是需要花费不少时间完成优化和适配的。特别是 AEC，AGC，ANS 等 3A 算法，以及弱网对抗相关内容。而且就算这些内容都学完了，可以搭建起来了，但是效果如何，还是一个未知数。

至于第三方的 SDK 调研，网上有个大佬总结的笔记还不错，将相关内容整理一下内部讨论了一下，作为 Plan B，相关链接如下：

https://blog.csdn.net/qq_33443989/article/details/84232061

其中声网无论在平台支持度，传输协议的满足，以及浏览器的兼容性都体现了足够的专业性，也是上市公司，但价格却是一个非常大的掣肘，对我们这些小公司来说，费用还是非常可观的。

目前音视频公司都处在从分发能力转向追求更好用户观看体验的过程中，注重技术从学术界向工业界的转化，加快从标准到落地的速度。当在线视频服务希望进一步优化他们的编码质量时，却会遇到一个关键问题——如何认定优化确实是有效的。

就在自己一筹莫展的时候，网上看到一篇帖子，有介绍广州擎声科技的音频SDK，可以兼容声网，也有自主研发的算法，效果还不错，就尝试巴拉一下demo进行体验。感觉还不错，我们能用到的场景下和声网效果持平。从官网上可以查到：擎声 QttAudio 是电子科大的声学实验室自研的引擎，出海延迟控制得还不错，都是 170ms 以下；也支持弱网 60%的丢包恢复，导入也还算简单，可以通过 gradle 或者 sdk 集成。和客户联系还可以直接兼容声网的 SDK，一套代码，两种体验效果。关键是价格是非常惠民的，4.99 元/1000 分钟，比声网少了将近 30%，联系客服又打了一个折，真是非常香~~这样一年下来能节省一笔不菲的开支。据百度查询，该公司也获得数千万的融资，能够得到这样的投资，应该效果还不错。

目前已经推荐给部门经理和 CTO 进行评估，待上线效果稳定后，再跟大家分享吧。

-------------------------------------------时间分割线----------------------------------------

最近不少私信在追我要上线后续，不好意思，这就补上。

最后上线了声网和擎声的 SDK，不过也没感受出来两家有啥差别，后面就把量配给了擎声，毕竟价格优势摆在那，用了这么久也挺稳定，都没找过售后支持。

经过这样一段极其痛苦，效率低下的阶段后，自己明白了一个道理：要搭建一个框架，就类似承建一座大厦，要从宏观全局角度去考量，首先需求是什么，使用场景是什么，要满足什么规格，要服务哪些人群。当我们去审视整个过程时，仅把它形容为一座大厦又显得如此不贴切，甚至也不能用“一个城市”去形容它，事实上，它更像是一个无中生有的全新世界：在其中，有个体、有族群、有生态，还有喜怒哀乐。而技术仅仅是支持这些需求的武器，有好的技术肯定会解决问题更快速，更方便，体验更好。但是解决问题也是一个综合考量的过程，是一个局部追求最优解的过程，类似动态规划。只有让自己生存下来，才能够追求更好的技术。否则一切都是杂谈（扯淡）。