聊聊音频类开源代码这点事

我工作的头几年是在通信设备商做通信设备上的语音软件开发,主要是follow ITU-T/3GPP/RFC等SPEC写代码,相对封闭,没怎么接触开源代码。后来到芯片公司做终端上的voice engine,开始接触音频类的开源代码,先是ITU-T/3GPP的各种codec,后来是各种完整的解决方案。刚开始做voice engine的时候,GIPS还没被Google收购,更加没有webRTC的开源,那时腾讯QQ上的语音方案还没自研(用的是GIPS的方案)。到现在用过的音频类开源代码个数虽然没具体统计过,至少也有十几个吧,例如webRTC/PJSIP/FFMPEG。今天我们就聊聊音频类开源代码这点事。

 

音频类开源代码众多,我根据自己的使用以及理解将它们分成三类,如下表:

聊聊音频类开源代码这点事_第1张图片

算法类主要有ITU-T/3GPP codec reference code等,音频的算法主要是数字信号处理,技术门槛是很高的,ITU-T/3GPP等组织为了普及自己制定的codec,就开源了codec的软件实现方便大家使用,大家用时的主要工作就是优化代码,使其在具体的平台上流畅运行。解决方案类主要有webRTC/PJSIP等,包括了从采集、编解码、传输到播放的整个过程,并且对不同平台(Linux/Android/iOS)进行了适配。好多公司(尤其互联网公司)基于这样的开源实现做二次开发,形成自己的产品。这类开源实现中也用其他的开源代码,主要是算法类的,比如用ITU-T/3GPP各种codec的reference code,再比如PJSIP就用了webRTC里的AEC的开源实现。介于算法和解决方案之间的既不是单纯的算法,也没有形成一套完整的解决方案,比如FFMPEG,它除了各种算法之外,还有各种音频格式的封装和解封装等,但它没有形成完整的解决方案,而是提供API给其他模块用。

 

音频类代码的开源,不管是对行业对公司还是对从业的个人都是受益颇多。对行业而言,主要是降低了技术的门槛,促进了技术的普及,大家都来做了,也促进了行业的繁荣。要是没有webRTC的开源,短时间内肯定不会有音视频直播APP的集中涌现,更加不会有2016年全民玩直播的热潮。

 

对公司而言,主要有以下益处:

1,基于解决方案类的开源实现做产品,极大地缩短了产品的开发周期,让产品尽早的投放市场,获得先机和较好的市场份额。

2,音频处理中复杂的算法,比如AEC,都是有很高的技术门槛的,一般不可能在短时间内做出一个性能很好的软件实现。以前只有大公司或者专业的算法公司才做这些算法,一般公司都是去买算法库用到自己的产品里。现在这些算法开源了,可以拿来用,节省了一笔开支。

3,基于解决方案类开源实现做产品,就要对里面的机制技巧等搞清楚吃透,然后才能做二次开发。这样就逐渐的提高了整个团队的技术能力和竞争力。

 

对个人而言,主要有以下益处:

1,一些算法实现,如果只有文档,可能理解的不是很深刻,有了代码实现后就可以去调试,更好的理解算法。

2,著名的解决方案类开源实现都是技术大牛写出来的,里面有很多的技巧和设计的思想,把这些都理解了后就无形中提高了自己的编程架构等能力。大家做东西一般都不是从零开始的,而是先学习他人的,理解消化后再根据自己开发产品的需要做改进。以我自己为例,以前对jitter buffer只有一个基本的概念,并不知道如何实现,后来学习了开源里的实现,理解消化后并做了一定的改进用到了自己开发的产品里。

 

音频类开源代码也有自己的一些特点:

1,对算法类开源实现而言,尤其是各种codec的reference code,一般都不能直接使用(主要是因为CPU load 高),而是优化后才能使用。

2,对解决方案类开源实现而言,一般会适配各种平台各种协议,因而是包罗万象的,有的还增加了适配层,这些处理增加了代码的复杂度,加大了代码走读的难度。同时这些代码都是大牛写的,技巧性很强,也加大了代码走读的难度。我记得刚开始读PJSIP代码时特别晕,好多抽象出的适配层,到处是callback函数,而且这些callback函数的名称都一样,只有加log才知道这个函数在哪调的。后来代码熟悉了知道这些callback函数在哪调才好很多。

 

就我自己而言,既在产品开发中用过算法类开源实现,也有基于解决方案类开源实现开发产品。我的看法是算法和模块可以用开源的,但是整个解决方案最好不要用开源的,即使刚开始为了赶进度用开源的,后面有时间了也要自己重写。因为解决方案类开源是保罗万象的,而我们自己开发的产品平台和协议等都是明确的,这样可以减少代码的复杂度冗余度,也有利于后期的维护(我看到一些基于解决方案类开源做的产品越到后面越难维护,不得不重写)。同时开源实现中好多会用非常复杂的数据结构,有时还有多层的封装,代码走读性不够友好。我喜欢的代码风格是简洁明了,能用简单的数据结构就不用复杂的,即使是刚毕业的学生也能很快看懂,也有利于后期的维护。记得在开发过的一款产品里前人用双向链表(buffer动态分配不固定)来存储从网络上收到的语音包,通常情况下都没有问题,但是网络状况多变,好多场景是设计时想不到的,只有出问题了才意识到。而且出问题基本上都是指针飞了crash,如果没有很好的定位crash的手段,再加上log又不是实时的,不知道crash在什么地方,会很痛苦。当时就填了好多这样的坑。后来我们用循环数组替换了双向链表,存放语音包的buffer是一块连续的空间,代码好理解,也很少出crash的问题,即使出crash问题也能很快定位解决。所以我觉得能用数组解决问题的就不要用链表,数组(循环数组/ring  buffer)是我这么多年用的最多的数据结构,而链表是很少用的。

转载于:https://www.cnblogs.com/talkaudiodev/p/8545533.html

你可能感兴趣的:(数据结构与算法,ffmpeg,移动开发)