谈起 Opus，对于编解码器有所了解的同学也许会知道，Opus 是由两个编解码器——Silk 和 Celt 融合而成。为什么来自两个组织的编解码器会合二为一，Opus 的性能又如何，本文将简述一下 Opus 的前世今生和部分技术分析。
提到 Opus，就不得不提到它的主要作者，Jean Marc Valin，他从学生时代就开始致力于高音质编解码算法的实现，著名的编解码器 Speex 也是他的作品之一。时间回到2007年，Jean Marc Valin 在博士后期间，完成了 Speex 的开发。在当时，业内编解码器主要分为两个流派：高延时的音乐编解码器（如 MP3、AAC 和 Vorbis）和低延时的语音编解码器（AMR、Speex、G.729）。而工业界对低延时音乐编解码器的需求越来越高，于是 Celt 的开发也被提上了日程。Celt 的早期目标是实现 4-8ms 的编码延时，相比当时 MP3 和 AAC 编码的 100ms+ 延时，优势是非常巨大的。
本文分享了声网Agora 首席音频工匠高泽华在 RTC 2018 实时互联网大会上，以《SOLO X™：兼容 WebRTC 标准的抗丢包语音编码器》为题的演讲。主要介绍了声网推出的抗丢包语音编码器 Agora SOLO™ 的算法特点，以及第二代编解码器 Agora SOLO X™ 的新特性与测试效果。以下为演讲实录。
去年，我们在 RTC 大会上分享了自主研发的抗丢包编解码方案 Agora SOLO™ ，主要是面向抗丢包网络，解决实时通信传输 last mile 的问题。
有时，大家对丢包问题会有一些误解。很多人认为随着 4G 的普及和 5G 的建设，是不是丢包问题变得不重要了？我认为并不是这样，因为在现有网络条件下，不论是 server 到 server，还是 sever 到 last mile 都存在着大量的丢包问题。
我们谈到丢包就涉及到丢包的概念，到底什么叫做丢包？其实任何没有按时到达的包都是丢包。如果把一个包的延时拉到足够大，一般来说，我们可以通过无数次重传来解决丢包问题。如果这个包没有在规定的时间到达，都算丢包。而且，丢包也不一定是网络原因导致，有时候是由于系统的调度等原因造成。
举个例子。通常，Android 系统上播放线程、解码线程和收包线程都可以不是一个线程。Android 并不是特别实时的操作系统。一旦系统比较忙的时候，就容易产生收包线程和解码线程的冲突，导致丢包产生。而这种丢包是由于系统产生的。甚至在解码时，解码器完成解码后交给播放器播放，其中的 buffer 也会导致卡顿。
丢包也与带宽限制相关。如果带宽足够大，可以通过无数次重传来实现抗丢包效果。但如果带宽很有限，就不能完全依靠无限制的重传来实现抗丢包效果。
比如说，曾经联通做过这样的事情，流量包月，但每个月的带宽只能在 128kbps，满足你对网页和音视频的基本需求。在这种服务下，如果你开一些高性能或者大码率的信源通讯的时候就会产生带宽拥塞，带宽拥塞首先导致延时增加，下一步就会产生丢包。所以，实际上带宽和丢包也相关。
由于我们声网在全球布网，非洲、东南亚、中东和印度的网络状况与中国的网络状况相差还比较远。即使在中国的网络环境下，上海和偏远地区的网络状况也是不一样的。所以，并不是以后上了 5G 就不存在丢包问题了，相反，我认为随着网络的差异化会导致丢包的问题变得越来越普遍。
这是由一篇我的演讲稿整理出来的文章，目标读者是对音视频开发感兴趣但是又不知道如何下手的初学者们，希望把我的经验分享出来，对大家有所帮助。
经常收到一些网友的来信或者留言，反馈如下这样的困惑：
“我是一名应届毕业生，该如何快速地成长起来”
“我只懂 C/C++，是学 Android 开发有前途，还是 iOS 开发有前途？”
“我是一名 Android/iOS 开发，已经可以独立完成一个完整的 App 开发上线，该如何继续提升？”
“我想从事音视频开发，该如何入门？ 如何进阶 ？”
很高兴看到大家有这样的问题，因为这也从侧面反映了你是一个积极向上，想不断努力来提升自己的人。
我就先从一个简单的问题聊起，“到底 Android 开发有前途还是 iOS 开发有前途？”
最近实验了下如何让WebRTC支持H264编码，记录下，供有需要的人参考。
说明一下，我是在 Ubuntu Server 14.04 下编译的 WebRTC ，使用 native（C++） api 开发 WebRTC 应用。所以我的调整都是基于 native 代码。
最终的效果是浏览器可以用H264发送视频，也可以接收H264视频。
注意，WebRTC 使用 OpenH264 来做 encoder （见 h264_encoder_impl.cc），使用 ffmpeg 来做 decoder （见 h264_decoder_impl.cc ）。
代码版本
本文对应的代码是2017年2月8号的，可以使用 gclient revinfo -a来查看具体版本，如下：
WebRTC 自诞生之日起, 就代表了实时通信领域的最好的技术. 不过很长时间里, 它所支持的视频编码器只有VP8, 后来随着H265/VP9为代表的下一代视频编码器的诞生, WebRTC里出现了VP9 Codec. 而当前应用最广泛的H264 却一直不受待见. 一直到Cisco 宣布旗下的H264 Codec开源为OpenH264, 并且替所有OpenH264的使用者支付了H264的专利费， 以次为契机， 在IETF的WebRTC会议中， 把H264和VP8都列入了WebRTC所必需要支持的视频编码器。 接下来， Google终于在WebRTC中增加了对H264的支持， 在PC平台(Windows和MAC), 编码器是用OpenH264, 解码器是用FFMPEG， 在iOS平台上， 编码器和解码器既可以使用OpenH264和FFMPEG, 也可以用apple的VideoToolbox所支持的硬件编解码器. 在Android平台, 可以用 OpenH264, FFMPGE, 也可以用 MediaCodec. 这个对于广大需要H264的公司来说是一大福音. 在下载的WebRTC代码中做稍许配置， 就可以使用H264了.
WebRTC音频引擎的实现代码主要分布在如下几个源码目录中：
webrtc/audio
webrtc/common_audio
webrtc/media/engine
webrtc/voice_engine
webrtc/module/audio_coding
webrtc/module/audio_conference_mixer
webrtc/module/audio_device
webrtc/module/audio_processing
WebRTC音频引擎的整体架构如图1所示。
WebRTC技术的出现改变了传统即时通信的现状，它是一套开源的旨在建立浏览器端对端的通信标准的技术，支持浏览器平台，使用P2P架构。WebRTC所采用的技术都是当前VoIP先进的技术，如内部所采用的音频引擎是Google收购知名GIPS公司获得的核心技术：视频编解码则采用了VP8。
大家都说WebRTC好，是未来的趋势，但是不得不说这个开源项目对新手学习实在是太不友好，光是windows平台下的编译就能耗费整整一天的精力，还未必能成功，关于这个问题在我之前的文章中有所描述。编译成功之后打开一看，整个solution里面有215个项目，绝对让人当时就懵了，而且最重要的是，google方面似乎没给出什么有用的文档供人参考，网络上有关的资料也多是有关于web端开发的，和Native API开发有关的内容少之又少，于是我决定把自己这两天学习VideoEngine的成果分享出来，供大家参考，有什么问题也欢迎大家指出，一起学习一起进步。
首先需要说明的是，webrtc项目的all.sln下有一个vie_auto_test项目，里面包含了一些针对VideoEngine的测试程序，我这里的demo就是基于此修改得到的。
总述
WebRTC原生支持VP8和VP9，但也可以自行集成H264编解码器，比较常见的是OPENH264和X264（X264自身只有编码功能，如果要加入解码功能，可以再结合ffmpeg），总体来说，集成H264编解码器的流程和直接使用它们的库的流程类似，但是要先将相应功能依照WebRTC中对编解码器的封装形式重新封装，然后再通过注册外部编解码器的方法在主流程中使用它们。
下面先看一下WebRTC对编解码器的封装形式是怎么样的，定义在webrtc\modules\video_coding\codecs\interface\video_codec_interface.h中，如下
1. X264显式支持的一趟码率控制方法有：ABR, CQP, CRF. 缺省方法是CRF。这三种方式的优先级是ABR > CQP > CRF.
if ( bitrate ) rc_method = ABR;
else if ( qp || qp_constant ) rc_method = CQP;
else rc_method = CRF;
bitrate和QP都没有缺省值，一旦设置他们就表示要按照相应的码率控制方法进行编码，CRF有缺省值23，没有任何关于编码控制的设置时就按照CRF缺省值23来编码。
总述
在前一篇文章中，讲解了如何将OPENH264编解码器集成到WebRTC中，但是OPENH264只能编码baseline的H264视频，而且就编码质量而言，还是X264最好，本文就来讲解一下如何将X264编码器集成到WebRTC中，为了实现解码，同时要用到ffmpeg。总体流程和之前一样，分为重新封装编解码器和注册调用两大步骤，注册调用这一步没有任何不同，主要是重新封装这一步骤有较大区别。
重新封装X264编码功能
首先当然还是要下载X264源码编译出相应的库以供调用。在windows下使用mingw进行编译，再使用poxports工具导出库，最后得到libx264.dll和libx264.lib，同时把x264.h和x264_config.h总共四个文件放到工程目录下，并在项目属性中进行相应配置。
众所周知，Chrome/WebRTC中的视频编解码器一直使用Google自己开发的VP8/VP9，而对于业界广泛使用的H264则支持有限。他们这么做除了推广自家产品外，还有一个很好的理由：专利。VP8/VP9是免专利费的，而H264则需要专利授权。因此，Google Chrome在2011年的时候甚至放弃对H264的支持。
但是，随着H264的发展，Chrome不得不再次考虑对H264的支持问题，特别是思科发布H264开源实现openh264后。最近，Google宣布从Chrome50开始支持H264视频编解码，用户在打开Chrome时通过如下命令行参数即可启用：
--enable-features=WebRTC-H264WithOpenH264FFmpeg
这无疑是一个好消息，尤其对研究WebRTC的开发者来说，在WebRTC中启用H264可以明显带来如下收益：
1. 浏览器互操作：除Chrome和Firefox外，目前微软Edge浏览器的ORTC也开始支持H264/AVC。
2. 移动设备支持：移动设备基本上都支持H264硬件编解码。
3. 遗留系统互连：遗留视频系统基本上都使用H264，绝大多数不支持VP8。使用H264可使得WebRTC和这些系统方便互通。
在前一篇文章中，講解了如何將OPENH264編解碼器整合到WebRTC中，但是OPENH264只能編碼baseline的H264視訊，而且就編碼質量而言，還是X264最好，本文就來講解一下如何將X264編碼器整合到WebRTC中，為了實現解碼，同時要用到ffmpeg。總體流程和之前一樣，分為重新封裝編解碼器和註冊呼叫兩大步驟，註冊呼叫這一步沒有任何不同，主要是重新封裝這一步驟有較大區別。
WebRTC 把H264和VP8都列入了WebRTC所必需要支持的视频编码器。同时联播可以同时使用多个编码器提供同一个媒体不同的分辨率来供人们选择以适应带宽波动（和其它）。不幸的是，libwebrtc没有实现对带有H.264编解码器的同时联播的支持。H.264实际上是间接的编解码器，因此只支持H.264的Safari不能实现与VP8和其他浏览器相同程度的编解码质量。本篇博客将详述如何解决此问题，实现方法与设计，和WebRTC产品的影响。
H.264被设定为取代VP8成为WebRTC服务的视频编解码器。
微软上周在他们的Edge开发博客上宣布， Edge的ORTC开始支持H.264/AVC。
· 是的，它是ORTC而不是WebRTC
· 是的，它仅通过运行时标志就可以开启
· 是的，它只在Edge浏览器可用，IE浏览器不行
但话又说回来，这是目前唯一能够在Firefox、Chrome和Edge之间跨浏览器进行视频通话的方法。VP8和VP9至多能让你在Chrome和Firefox之间建立视频通话。
这也是我写这篇文章的原因。Edge在ORTC中对H.264的支持并不多。从更大的视角来看，这甚至谈不上有意义。相比于其他浏览器Edge几乎没有市场份额，那么为什么还要为它花费心思呢？但是这件事仍然标志着一个转折——我们应当问自己：当我们要开发一个基于WebRTC的产品时，我们应该选择什么样的视频编解码器。
去年的时候，这个答案可能是“VP8”。
几个月前，答案可能是“看情况”。
现在，答案将会是“除非必须用VP8，否则就用H.264”。
当我们使用像Skype、QQ这样的工具和朋友流畅地进行语音视频聊天时，我们可曾想过其背后有哪些强大的技术在支撑？本文将对网络语音通话所使用到的技术做一些简单的介绍，算是管中窥豹吧。
网络语音通话通常是双向的，就模型层面来说，这个双向是对称的。为了简单起见，我们讨论一个方向的通道就可以了。一方说话，另一方则听到声音。看似简单而迅捷，但是其背后的流程却是相当复杂的。我们将其经过的各个主要环节简化成下图所示的概念模型：
这是一个最基础的模型，由五个重要的环节构成：采集、编码、传送、解码、播放。
语音采集指的是从麦克风采集音频数据，即声音样本转换成数字信号。其涉及到几个重要的参数：采样频率、采样位数、声道数。
简单的来说：采样频率，就是在1秒内进行采集动作的次数；采样位数，就是每次采集动作得到的数据长度。
而一个音频帧的大小就等于：（采样频率×采样位数×声道数×时间）/8。