轻口味的专栏

源码:本地代码:JNI代码:JAVA代码:前面我们已经介绍过 OpenGL ES/EGL Wrapper 库是一个将 OpenGL ES API 和 OpenGL ES API 具体实现绑定在一起的库，它对应的源码路径是：/frameworks/native/opengl/libs/，其中:libGLESv1_CM.so：OpenGL ES 1.x API 的 Wrapper 库libGLESv2.so：OpenGL ES 2.0 的 Wrapper 库libGLESv3.so：OpenGL ES 3

混合就是把两种颜色混在一起。具体一点，就是把某一像素位置原来的颜色和将要画上去的颜色，通过某种方式混在一起，从而实现特殊的效果。假设我们需要绘制这样一个场景：透过红色的玻璃去看绿色的物体，那么可以先绘制绿色的物体，再绘制红色玻璃。在绘制红色玻璃的时候，利用“混合”功能，把将要绘制上去的红色和原来的绿色进行混合，于是得到一种新的颜色，看上去就好像玻璃是半透明的。即可。即可。只有在RGBA模式下，才可以使用混合功能，颜色索引模式下是无法使用混合功能的。

本文介绍了OpenGL相关的空间和坐标体系，以及从3维到2维的投影过程及成像原理，最后介绍了平移、缩放、旋转三种变换的数学及矩阵表示。

本文介绍了Android系统提供的GLSurfaceView的用法及绘制一个最基本的图像：三角形用到的API：设置清屏色、启用顶点缓存、设置视口、设置投影矩阵等。

Shader 用来描述如何绘制（渲染），GLSL 是 OpenGL 的编程语言，全称 OpenGL Shader Language，它的语法类似于 C 语言。OpenGL 渲染需要两种 Shader：Vertex Shader 和 Fragment Shader。在 OpenGL 的世界里，我们只能画点、线、三角形这三种基本图形，而其它复杂的图形都可以通过三角形来组成。OpenGL 中有两种流水线，一种是固定流水线，另外一种则是可编程流水线。而光栅化是把点、线、三角形映射到屏幕上的像素点的过程。

There are a few ways to get FFmpeg on OS X.使用从github下载ffmpeg源码,切换到要使用的目标分支(这里使用release/3.3):,或者直接从github下载分支的压缩包,解压.Starting with Lion 10.7, Xcode is available for free from the Mac App Store and is required to compile anything on your Mac. Make sure you i

设置与获取都是对AVStream的dict操作.

这里有一个说明是可以传递NULL，什么情况下需要传递NULL，你平时看一些视频播放器，播放经常会少最后几帧，很多情况就是因为没有处理好缓冲帧的问题，ffmpeg内部会缓冲几帧，要想取出来就需要传递空的AVPacket进去。解码后图像空间由函数内部申请，你所做的只需要分配 AVFrame 对象空间，如果你每次调用avcodec_receive_frame传递同一个对象，接口内部会判断空间是否已经分配，如果没有分配会在函数内部分配。ffmpeg3版本的解码接口做了调整,之前的视频解码接口。

上述序列中，WebRTC并不提供Stun服务器和Signal服务器，服务器端需要自己实现。Stun服务器可以用google提供的实现stun协议的测试服务器（stun:stun.l.google.com:19302），Signal服务器则完全需要自己实现了，它需要在ClientA和ClientB之间传送彼此的SDP信息和candidate信息，ClientA和ClientB通过这些信息建立P2P连接来传送音视频数据。stun/turn、relay服务器的实现在WebRTC源码中都有示例。

webrtc的base的 thread，是我见过的封装最帅的c++线程库，根据比qt的还好用,发个例子给你有ios的gdc，android的handler异曲同工因为编写复杂稳定的多线程C++项目实在太难，所以一个好的跨平台C++基础库是我最求的目标,目前比较欣赏的项目有：Boost:大而全，缺少一些可以直接上手的东西如线程消息队列，智能指针并非线程安全。QT core：非常好C++11：也需要线程消息队列，线程安全智能指针。chromium的base库：太大了。

对于实时音视频应用来讲，媒体数据从采集到渲染，在数据流水线上依次完成一系列处理。流水线由不同的功能模块组成，彼此分工协作：数据采集模块负责从摄像头/麦克风采集音视频数据，编解码模块负责对数据进行编解码，RTP模块负责数据打包和解包。数据流水线上的数据处理速度是影响应用实时性的最重要因素。与此同时，从服务质量保证角度讲，应用需要知道数据流水线的运行状态，如视频采集模块的实时帧率、当前网络的实时速率、接收端的数据丢包率，等等。

SDP 完全是一种会话描述格式 ― 它不属于传输协议 ― 它只使用不同的适当的传输协议，包括会话通知协议（SAP）、会话初始协议（SIP）、实时流协议（RTSP）、MIME 扩展协议的电子邮件以及超文本传输协议（HTTP）。SDP协议是也是基于文本的协议，这样就能保证协议的可扩展性比较强，这样就使其具有广泛的应用范围。SDP 不支持会话内容或媒体编码的协商，所以在流媒体中只用来描述媒体信息。

使用call对象以及PeerConnectionFactory中channel_manager(PeerConnectionFactory中Initialize中创建)构造WebRtcSession对象session_,调用Initialize方法初始化session_,初始化session_槽函数等.session_初始化方法中创建WebRtcSessionDescriptionFactory对象webrtc_session_desc_factory_.WebRtcVideoEngine2定义在。

既然WebRTC是用C++来实现的,可以用JNI来调用Android的API,那能不能不通过JNI调用JAVA,而是直接调用他底层的实现类库呢?对于Android NDK开发来说,通过JNI调用OpenSL ES 提供的API,您即可实现大部分音频操作需要而不用在通过Java来操作.通过调用Android提供的AudioManager类来操作音频设备(webrtc是用C++写的,通过JNI来调用这些JAVA方法).

ts是日本高清摄像机拍摄下进行的封装格式，全称为MPEG2-TS。ts即"Transport Stream"的缩写。MPEG2-TS格式的特点就是要求从视频流的任一片段开始都是可以独立解码的。MPEG2-TS主要应用于实时传送的节目，比如实时广播的电视节目。

gclient文件是gclient的控制文件，该文件放在工作目录的最上层(webrtc环境下与src统计目录)。deps的每个条目都包含一个key-value对，key是被checkout的本地目录，而value就是对应的远程URL。Hooks：DEPS包含可选的内容 hooks，也有重要的作用，它表示在sync, update或者recert后，执行一个hook操作。deps_os指定不同平台的依赖，它可以包含多种平台，和.gclient中的target_os对应。

MP4文件中的所有数据都装在box（QuickTime中为atom）中，也就是说MP4文件由若干个box组成，每个box有类型和长度，可以将box理解为一个数据对象块。box中可以包含另一个box，这种box称为container box。一个MP4文件首先会有且只有一个“ftyp”类型的box，作为MP4格式的标志并包含关于文件的一些信息；之后会有且只有一个“moov”类型的box（Movie Box），它是一种container box，子box包含了媒体的metadata信息；

FLV（Flash Video）是现在非常流行的流媒体格式，由于其视频文件体积轻巧、封装播放简单等特点，使其很适合在网络上进行应用，目前主流的视频网站无一例外地使用了FLV格式。另外由于当前浏览器与Flash Player紧密的结合，使得网页播放FLV视频轻而易举，也是FLV流行的原因之一。FLV是流媒体封装格式，我们可以将其数据看为二进制字节流。总体上看，FLV包括文件头（File Header）和文件体（File Body）两部分，其中文件体由一系列的Tag及Tag Size对组成。

MP3 文件是由帧(frame)构成的，帧是MP3 文件最小的组成单位。MP3的全称应为MPEG1 Layer-3 音频文件，MPEG(Moving Picture Experts Group) 在汉语中译为活动图像专家组，特指活动影音压缩标准，MPEG 音频文件是MPEG1 标准中的声音部分，也叫MPEG 音频层，它根据压缩质量和编码复杂程度划分为三层，即Layer-1、Layer2、Layer3， 且分别对应MP1、MP2、MP3 这三种声音文件，并根据不同的用途，使用不同层次的编码。

机器学习现在应用的主要领域还是NLP、语音识别、图像识别等，之前谷歌推出了基于机器学习的语音编解码器Lyra。通过语音和视频通话与他人在线联系正日益成为日常生活的一部分。实时通信框架，如WebRTC，使这成为可能，依赖于有效的压缩技术，编解码器，编码(或解码)信号传输或存储。几十年来，编解码器一直是媒体应用的重要组成部分，它使需要带宽的应用程序能够有效地传输数据，并使人们期望在任何时间、任何地点都能实现高质量的通信。

目前在视频编解码器中，H264已经成为绝对的主流，被大部分设备、浏览器所支持。虽然有更先进的编码器推出，但是受限于推广速度和设备支持成本，一直未能成为主流。今年公司目标是持续降本增效，现在将”屠刀“指向了视频业务的存储成本。视频文件存储主要两块指标：存储本身和CDN资源。对于历史比较旧的数据会用更低成本的存储方式备份存储。目前主要想优化存储本身的成本。对存储成本影响最大的是文件大小，而对文件大小影响最大的是视频码率，我们想要降低文件大小就要降低视频码率，但是我们想要降低码率又不太影响视频观看质量怎么办？

以上的WebRTC产生的默认配置，这种配置下，音频采样率是48000，音频打包时间是10ms,单声道，编码采用的是Opus里面的silk编码，适合传人声，不适合传音乐。WebRTC中默认是采用Opus编码，Opus编码是由silk编码和celt编码合并在一起，silk编码是由skype公司开源的一种语音编码，特别适合人声，适合于Voip语音通信。Opus支持8000，12000,16000，24000，48000 这几种采样率，比如我们现在如果要设置音频采样率为8000，我们应该如何做呢？

只有在保持信号质量的前提下，设法降低码率及数据量，才能使标准得到应用。而这种降低码率的过程，被称为压缩编码或新源编码.这节介绍一些基础的压缩编码思想与方法,为后面Opus语音编码做基础准备.压缩编码又可以分为无损压缩,有损压损,混合压缩视频编码比语音编码描述更直观,本文以视频编码示例讲解主要的压缩编码原理.

前面我们分析完Opus的编解码api使用,封装原理等,接下来我们准备分析Opus编码原理.Opus编码是一个复杂的工作,我们需要做一些基本铺垫,包括认识声音,压缩编码基础.认识音频有助于我们了解音频特征,不仅对语音有助于我们理解编码技术,同时在语音识别,TTS等场景提供帮助。

译]Ogg bitstream overview[译]ogg logical bitstream framing[译]Page Multiplexing and Ordering in a Physical Ogg Stream[译]The Ogg Skeleton Metadata Bitstream我们翻译了Ogg的官方文档,下面我们在对Ogg做一个简练的总结Ogg是一个自由且开放标准的多媒体文件格式，由Xiph.Org基金会所维护。

前面我们已经成功将PCM文件编码成Opus,写入文件,接下来我们实现解码.

前面介绍了opus编解码器的API,这边文章介绍编码API的具体使用示例.分Android,ios,Linux三个系统进行实现.编码是我们对脉冲编码调制(Pulse Code Modulation,PCM)的数据进行压缩操作,我们通常通过操作系统麦克风API获取PCM数据,或者从存储的现成的文件的PCM数据:PCM数据大小怎么计算呢?根据采样率采样格式,声道数计算.根据前面文章介绍:PCM文件大小 = 采样率 * 采样格式 * 声道数 * 录制时长。

typedef struct OpusEncoder OpusEncoder //Opus encoder 状态.typedef struct OpusEncoder OpusEncoder //Opus编码器状态。这包含了一个Opus编码器的完整状态。它是位置独立的，并且可以自由复制。typedef struct OpusDecoder OpusDecoder //Opus 解码器状态.typedef struct OpusDecoder OpusDecoder //Opus 解码器状态.

Opus编解码器是专门设计用于互联网的交互式语音和音频传输。它是由IETF的编解码器工作组设计的，合并了Skype的SILK和Xiph. Org的CELT技术。Opus编解码器的设计目的是处理广泛的交互式音频应用程序,包括IP语音,视频,游戏内聊天,甚至远程现场音乐表演。它可以适用于从低码率窄带语音到非常高质量的立体声音乐。

接下来要实现connect,createStream,play,…,为了效率和篇幅,我们直接分析的实现.srs-librtmp是从srs作者为srs服务实现的客户端库(The client library srs-librtmp of SRS),其实不止客户端,也实现了一个简单的server功能.

RTMP是基于TCP协议的应用层协议,默认通信端口1935.实现握手协议前先了解一下rtmp握手协议吧!!!

前面中我们已经搭建好服务器,并且利用一些现成的工具可以推送直播流,播放直播流了.这篇文章我们开始搭建从零开发一套rtmp推流拉流sdk,对着协议实现,达到真正的"深入理解".作为一个码农,搬砖搬到一定高度就需要"脚手架"来支撑我们"够得住".为了方面我们把rtmp推拉流sdk实现为一个PC上的命令行程序,当开发调试稳定后,我们可以快速的通过交叉编译工具编译到Android/iOS等移动端设备.

手机直播在15年的时候突然火起来,随着花椒,映客等出现,直播一下就出现在了风口,各个公司针对直播的战斗迅速打响,战斗过程比较短暂,随着许多公司的退出和死去,手机直播行业趋于稳定,直播服务时长也被传统的CDN厂商牢牢占据,后面大家又把精力投入到互动直播上面,当时一下对手机直播失去了信心.现在随着5G时代的到来,VR技术的兴起,就像15年前的短视频,在17年以后又开始发力一样,直播可能还会迎来它的第二春.趁着有点时间,准备再把直播领域的东西捡起来,从协议实现到编码到采集,逐渐深入并分享出来.

本文总结了TTS的现状及发展，并介绍了移动端实现TTS的几种方式以及如何系统提供的TextToSpeech API、系统API的局限、如何做兼容性等。

本文介绍了信号处理模块的各个功能点以及在移动端语音处理中的作用。还介绍了信号处理的基础知识以及常用工具。

有Android开发的小伙伴问有没有系统学习音视频的路线或者资料,今天抽空写一篇文章,整理一条从难到易从浅入深的路线,并配套对应的主流代码库.音视频从采集到播放都经历了哪些流程呢::通过上面的图,我们简单的把音视频方向分为主要的两块:我们这篇文章不再从音视频专业知识开始,而Android系统API的角度,逐层深入.我们最开始接触的摄像拍照是通过Intent调用系统摄像头:我们要播放视频最原始的是基于VideoView系统控件.但是系统相机和系统控件VideoView的局限性都是可定制型太差,系统相机的图像

视频画面添加水印；视频画面亮度调整；视频画面对比度调整；视频画面旋转；视频画面镜像；视频尺寸调整；视频图像模糊；两路视频融合。Mat类是Opencv中储存图像的一种数据结构。Mat类可以看做是存放矩阵的容器，他包含了两部分，分别是用来存放图片信息的信息头，和一个指向图片储存矩阵的指针。信息头往往占用空间比较小，而且各个图片之间的信息头是完全独立的。而图片储存矩阵往往占用较大的空间，并且可以多个图片的矩阵指针指向同一个内存空间。下面主要减少利用Mat创建矩阵。

15年移动端直播应用火起来的时候，主要的直播协议是RTMP，多媒体服务以Adobe的AMS、wowza、Red5、crtmpserver、nginx rtmp module等，后面过长RTMP服务SRS开始流行。Android端播放器主要以开始以EXOPlayer播放HLS，但是HLS有延迟高的确定，随后大家主要使用开源的ijkplyer，ijkplayer通过ffmpeg进行拉流及解码，支持多种音视频编码，还有跨平台，API与系统播放器保持一致等特征，后续各大厂提供的直播SDK均有ijkplayer身影。