等了一个星期，公司配备的iMac总算是到了，今天装上后体验了一下，有很多地方还是很不习惯，后面需要慢慢适应，这里列几点感悟。

过完一个周末来上班，今天被技术负责人约着谈了一下，主题是：让我转iOS开发。

其实在刚刚听到这个消息的时候，内心是窃喜的。因为自国庆以来，做的主要工作是预研性质的，诸如网络连接、音视频、图像处理这些非常专业的领域。也不是说自己不能够学习，主要是这些领域都是需要非常专业的人来做这些事情。通过我自学，预研，然后来做相关的开发，说实话，我自己都觉得不靠谱。所以一直以来，我对自己的工作都不是很不满意，虽然通过查资料，看文章，了解了相关东西的一点点皮毛，但是这些皮毛感觉没啥用，如果你不在这些专业的领域继续深挖进去，可以说我之前1、2月的工作都是做的无用功。当然，稍微拓宽了自己的知识层面这是不可否认的。

前言

通过前面一段时间的摸索，iOS的Multipeer Connectivity与Android的Wifi-Direct并不兼容，一些三方可能都是需要连接热点才能实现跨平台传输。热点是需要连接到同一个网络环境下的，那么考虑下Socket是否可行呢？理论上，应该是没问题的。为了验证，我这边便开始Android端的测试，至于跨平台就得等到iOS那边一起合作来验证了。

Socket连接

这里分一个Client（采集实时数据），一个server（接收数据进行处理）这样的两个角色。在一个局域网下，他们要互相建立连接首先便是要能互相发现。我的方案是：Server监听一个端口，Client发送一个绑定端口的广播（UDP），广播信息包含Client的ip，Server再收到广播之后，利用收到的ip发送一个单播到Client，单播信息包含Server的ip，Client收到之后便知道Server的ip了，那么便可以建立连接了。

现状

1. iOS：在iOS7中，引入了一个全新的框架——Multipeer Connectivity（多点连接）。利用Multipeer Connectivity框架，即使在没有连接到WiFi（WLAN）或移动网络（xG）的情况下，距离较近的Apple设备（iMac/iPad/iPhone）之间可基于蓝牙和WiFi（P2P WiFi）技术进行发现和连接实现近场通信。
2. Android：Wi-Fi peer-to-peer（P2P，对等网络），它允许具备相应硬件的Android 4.0（API level 14）或者更高版本的设备可以直接通过wifi而不需要其它中间中转节点就能直接通信（Android的Wi-Fi P2P框架符合Wi-Fi联盟的Wi-Fi Direct™直连认证标志）。使用这些API，你可以搜索并连接其它同样支持Wi-Fi P2P的设备，然后再通过一个高速的连接进行互相通信，并且这个连接的有效距离要比蓝牙连接的有效距离要长的多。这对于需要在用户之间共享数据的应用程序非常有用，例如多玩家游戏或者照片分享之类应用。

前言

通过我的上一篇文章，利用Camera实时采集视频，并用MediaCodec编码，可以得到YUV、H264文件了。那么接下来便是采集音频并编码了。

基础概念

在音频开发中，有一些基础的概念是必须要知道的。

采样率（samplerate）

采样就是把模拟信号数字化的过程，不仅仅是音频需要采样，所有的模拟信号都需要通过采样转换为可以用0101来表示的数字信号，示意图如下所示：

蓝色代表模拟音频信号，红色的点代表采样得到的量化数值。采样频率越高，红色的间隔就越密集，记录这一段音频信号所用的数据量就越大，同时音频质量也就越高。根据奈奎斯特理论，采样频率只要不低于音频信号最高频率的两倍，就可以无损失地还原原始的声音。通常人耳能听到频率范围大约在20Hz～20kHz之间的声音，为了保证声音不失真，采样频率应在40kHz以上。常用的音频采样频率有：8kHz、11.025kHz、22.05kHz、16kHz、37.8kHz、44.1kHz、48kHz、96kHz、192kHz等。

量化精度（位宽）

上图中，每一个红色的采样点，都需要用一个数值来表示大小，这个数值的数据类型大小可以是：4bit、8bit、16bit、32bit等等，位数越多，表示得就越精细，声音质量自然就越好，当然，数据量也会成倍增大。常见的位宽是：8bit 或者 16bit。

声道数（channels）

由于音频的采集和播放是可以叠加的，因此，可以同时从多个音频源采集声音，并分别输出到不同的扬声器，故声道数一般表示声音录制时的音源数量或回放时相应的扬声器数量。单声道（Mono）和双声道（Stereo）比较常见，顾名思义，前者的声道数为1，后者为2。

音频帧（frame）

音频数据是流式的，本身并没有明确的一帧帧的概念，在实际的应用中，为了音频算法处理/传输的方便，一般约定俗成取 2.5 ms ~ 60 ms为单位的数据量为一帧音频。 这个时间被称之为“采样时间”，其长度没有特别的标准。我们可以计算一下一帧音频帧的大小。假设某通道的音频信号是采样率为 8 kHz，位宽为16 bit，20 ms 一帧，双通道，则一帧音频数据的大小为：

1

int size = 8000 x 16bit x 0.02s  x 2 = 5120 bit = 640 byte

前言

通过我的上一篇文章，实时采集视频的LocalSocket方式在新的Android SDK上是跑不通的，那么便只剩下Camera了。本文将利用Camera来进行实时采集视频，MediaCodec进行硬编码来输出yuv、h264文件。

YUV

通过Camera采集到的原始数据是YUV（NV21）格式的，何为YUV？

YUV，分为三个分量，“Y”表示明亮度（Luminance或Luma），也就是灰度值；而“U”和“V” 表示的则是色度（Chrominance或Chroma），作用是描述影像色彩及饱和度，用于指定像素的颜色。YUV是一种颜色编码方法，主要用于电视系统以及模拟视频领域，它将亮度信息（Y）与色彩信息（UV）分离，没有UV信息一样可以显示完整的图像，只不过是黑白的，这样的设计很好地解决了彩色电视机与黑白电视的兼容问题。并且，YUV不像RGB那样要求三个独立的视频信号同时传输，所以用YUV方式传送占用极少的频宽。

YUV码流的存储格式其实与其采样的方式密切相关，主流的采样方式有三种，YUV4:4:4，YUV4:2:2，YUV4:2:0。

1. YUV 4:4:4采样，每一个Y对应一组UV分量。
2. YUV 4:2:2采样，每两个Y共用一组UV分量。
3. YUV 4:2:0采样，每四个Y共用一组UV分量。

这里只抛出这样一个概念，详情请参见文末的参考。

前言

通过我的上一篇文章，可以知道直播大致有几个步骤：音视频采集 -> 美颜/滤镜/特效处理 -> 编码 -> 封包 -> 推流 -> 分发 -> 解码/渲染/播放。那么首先便从采集开始，这里我先做的视频采集。
那么实时采集视频有哪些方案呢？

调研

通过各种调研，查阅文章，了解到目前Android实时采集视频大致有3种方式：

1. 通过Android Camera拍摄预览中设置setPreviewCallback实现onPreviewFrame接口，实时截取每一帧视频流数据
2. 通过通过Android的MediaRecorder，在SetoutputFile函数中绑定LocalSocket实现
3. 流媒体服务器方式，利用ffmpeg或GetStreamer等获取Camera视频

通过学习，大致了解了1，2两种方式的实现方式，但是对于第3种方式，暂时没有研究。

前言

2015 ~ 1016是直播大火的年代，最近公司也是在着手直播这块，作为Android开发，自然也要懂得一些知识，经过一段时间的调研，学习，作了一下自我总结，写了一个【Android音视频开发】系列，此文便是开篇了！
PS：关于这块的文章着实太少，点开10个链接，有7、8个链接的内容是一样的，各种转来转去，也是耗费了很大的功夫才了解到音视频的一点皮毛。而且很多文章都是12年、13年的，拿到现在可能根本就不适用，我通过实例验证，做下此总结。最近一直在看这一块的东西，今天抽空，趁着记忆的知识还比较新鲜记下来，好记性不如烂笔头，也希望能帮助到其他的人。

直播

从技术层面上来，直播大致分为：音视频采集、美颜/滤镜/特效处理、编码、封包、推流、分发、解码/渲染/播放。
对应到具体的Android层面，便会有如下几个重要环节：

1. 视频实时采集：Camera预览/MediaRecorder绑定LocalSocket
2. 音频实时采集：MediaRecorder/AudioRecord/OpenSL ES
3. 特效处理：视频磨皮美颜，音频降噪去回声等算法
4. 编解码：H264&AAC，MediaCodec(API >= 16)硬解，ffmpeg等三方库软解
5. 流媒体传输：rtmp rtsp hls等
6. 渲染播放：MediaPlayer，ijkplayer等三方库

之前写过一篇状态栏小记，这里加入虚拟按键重新做一下总结。

在我的上一篇文章中，尝试将弧形seekbar抽成了一个三方库，这篇文章便以该库为例，将其上传至JCenter。