gpuimage视频android
A. 有没有手机端用于rtmp推流(串流)直播的软件apk格式
播推流端即主播端，主要通过手机摄像头采集视频数据和麦克风采集音频数据，经过一系列前处理、编码、封装，然后推流到CDN进行分发。趣拍直播SDK可以满足以下所有的功能和应用场景，帮助开发者解决各种直播难题。采集手机直播SDK通过手机摄像头和麦克风直接采集视频数据和音频数据。其中,视频采样数据一般采用RGB或YUV格式、音频采样数据一般采用PCM格式。对于采集到的原始音视频的体积是非常大的，因此需要经过压缩技术来处理，降低视频的大小来提示传输效率。在手机视频采集方面，iOS系统在硬件的兼容性方面做得比较好，系统本身提供了比较完整的视频采集的接口，使用起来也比较简单。但是，Android系统就比较麻烦了，千奇百怪的机型都有，适配起来非常难。我们在初期做了一项调研，发现Android的适配率还不到50%。2.前处理在这个环节主要处理美颜、水印、模糊等效果。特别是美颜功能几乎是直播的标配功能，没有美颜的直播主播们根本提不起兴趣。我们见过太多case是因为没有美颜功能被抛弃使用的。另外国家明确提出了，所有直播都必须打有水印并回放留存15天以上。所以，在选择直播SDK时，没有美颜和水印功能基本就可以选择放弃了。美颜实际上是通过算法去识别图像中的皮肤部分，再对皮肤区域进行色值调整。通常情况下人的肤色与周边环境色调存在较大差异，通过颜色对比，找到皮肤的基本轮廓，进一步进行肤色检查还可以确定人脸范围。找到了皮肤的区域，可以进行色值调整、添加白色图层或调整透明度等来等来达到美白效果。美颜除了美白效果还需要磨皮功能，磨皮实际上就是用模糊滤镜实现的。滤镜有很多种，如高斯滤波，双边滤波，导向滤波，到底选择什么样的模糊滤镜各家也有自己的喜好。在美颜处理方面，最着名的GPUImage提供了丰富的效果，同时可以支持IOS和Android，还支持自己写算法实现自己最理性的效果。GPUImage本事内置了120多种常见滤镜效果，添加滤镜只需要简单调用几行代码就可以了，比如大家可以试试使用GPUImageBilateralFiter的双边滤波滤镜来处理基本的磨皮效果，想要实现更理想的效果还是要通过自定义算法去实现的，各家也都有自己一套算法。3、编码为了便于手机视频的推流、拉流以及存储，通常采用视频编码压缩技术来减少视频的体积。现在比较常用的视频编码是H.264，但具有更高性能的H.265编码技术正在飞速发展，并可能很快成为主流；在音频方面，通比较常用的是用AAC编码格式进行压缩，其它如MP3、WMA也是可选方案。视频经过编码压缩大大提高了视频的存储和传输效率，当然，经过压缩后的视频在播放时必须进行解码。通俗点讲就是编码器将多张图像进行编码后产生一段段GOP（GroupofPictures），播放时解码器读取一段段GOP进行解码后读取图像并进行渲染显示。在编码方面的核心是在分辨率、码率、帧率等参数中找到最佳平衡点，达到体积最小画面最优的效果，这些参数各家也都有自己的一套核心参数。2012年8月，爱立信公司推出了首款H.265编解码器，六个月后，国际电联(ITU)就正式批准通过了HEVC/H.265标准，称之为高效视频编码(HighEfficiencyVideoCoding)，相较于之前的H.264标准有了相当大的改善，做到了仅需要原来一半带宽即可播放相同质量的视频，低于1.5Mbps的网络也能传输1080p的高清视频。国内，如阿里云、金山云都在推自己的H.265编解码技术，随着直播的快速发展和对带宽的依赖，H.265编解码技术已有全面取代H.264的趋势。当然，全面推开应用还需要些时间。另外，硬件编码已经成为手机直播的首选方案，软编码处理在720p以上的视频颓势非常明显。在IOS平台上硬件编码的兼容性比较好，可以直接采用，但在Android平台上，Android的MediaCodec编码器，针对不同的芯片平台表现差异还是非常大的，要完全实现全平台兼容的4、推流要想用于推流还必须把音视频数据使用传输协议进行封装，变成流数据。常用的流传输协议有RTSP、RTMP、HLS等，使用RTMP传输的延时通常在1–3秒，对于手机直播这种实时性要求非常高的场景，RTMP也成为手机直播中最常用的流传输协议。最后通过一定的Qos算法将音视频流数据推送到网络断，通过CDN进行分发。在直播场景中，网络不稳定是非常常见的，这时就需要Qos来保证网络不稳情况下的用户观看直播的体验，通常是通过主播端和播放端设置缓存，让码率均匀。另外，针对实时变化的网络状况，动态码率和帧率也是最常用的策略。当然，在网络传输方面全部自己来做基本不现实，找提供推流服务的CDN服务商提供解决方案是最好的选择，可参考文章开头介绍的云视频服务商。据了解，阿里云是国内唯一能自研CDN缓存服务器的厂商，性能还是非常有保障的。通常，大多数直播平台都会同时接入多个视频云服务提供商，这样可以做拉流线路互备，对推流后视频集群再进行优化也可提高直播的流畅性和稳定性。
B. 短视频编辑：可实时交互的播放器
如何开发一个类似剪影或抖音的视频剪辑工具？
其开发任务如上图，一个短视频生产app的首要任务在于实现一个高度可实时交互的播放器，在播放预览时支持多种编辑能力。
最初我们调研了多种方案，乍一看Android原生播放器肯定不够用，估计要在众多c++的开源播放器中寻找参考方案，最好自己实现一个播放器，高度灵活高度可控。然而我们发现exo这个男团播放器的厉害之处，虽然这个播放器如此常用，但是我们不知道其潜力值爆表，可以拓展得如此强大。
事实上直到现在，我们仍然在自研视频剪辑工具中使用exoplayer做编辑预览。为什么选择exoplayer,基于以下几点原因（一句话，性价比高）：
使用基于exoplayer播放器进行二次开发，快速高效实现视频剪辑功能。视频剪辑播放器用于视频编辑过程中的实时预览播放，支持有功能有：
针对上述视频剪辑所需要支持的功能，逐一对照explayer的api文档，寻找拓展实现的方法。
其中，视频旋转、文字贴纸、美颜滤镜、素材转场需要调用setVideoSurface控制视频呈现层，自定义GLSurfaceView，使用opengl实现对视频的旋转、美颜滤镜、添加贴纸。exoplayer播放输出的surface与自定义GLSurfaceView的渲染纹理相绑定。
视频裁剪播放使用ClippingMediaSource设置裁剪素材，按api文档传入起始时间和结束时间。
多个视频拼接播放，使用ConcatenatingMediaSource可以用来无缝地合并播放多个素材，为了能对单个素材进行编辑，isAtomic设为true。
变速使用setPlaybackParameters设置速度参数
这三个功能使用exoplayer已提供的api就可以实现，相对容易。在执行编辑操作后即时更新播放器素材和参数即可。在我们的产品中，有一个撤销操作的交互，所以需要保留一份数据拷贝，如果用户撤销操作则更新为原来的数据。
exoplayer本身不支持图片格式的素材播放。注入一个自定义渲染器来实现图片（格式为jpg、png、gif等）
其中ImageRender继承BaseRenderer，实现了图片的自定义渲染。render主要工作是将每帧数据解码流渲染为屏幕图像。对于图片来说，我们定义ImageMediaSourceImage、SampleStreamImpl和ImageMediaPeriod，分别继承于BaseMediaSource、SampleStream和MediaPeriod，从原素材解析并传送每帧图片数据。图片不需要真正的解码，实现SampleStream的readData方法读取图片uri为解码buffer。
实现图片播放的核心在于实现render接口：
在这个方法内，我们创建opengl环境，将bitmap绘制到屏幕上
添加的文字或贴纸支持移动、旋转、缩放和设置时间轴。对于多个文字贴纸，我们最终包装为一个与渲染屏幕同尺寸的bitmap，在这个bitmap的画布上绘制一系列带坐标大小、起止时间的小bitmap(即stickerItem.getBitmap)。
将这张贴纸画布bitmap与原视频帧像素混合就实现了所有文字贴纸的绘制。用opengl绘制贴纸，就是对屏幕上像素做一个水印滤镜的运算。采用GLSL内建的mix函数做两个纹理的混合，以下是水印滤镜所用的片元着色器。
和文字贴纸一样，要实现实时的美颜滤镜效果，必须使用帧缓冲fbo。帧缓冲的每一存储单元对应着屏幕每一个像素。而美颜滤镜涉及较复杂算法，由部门内的人工智能组提供sdk接入，在绘制过程中调用sdk方法如下，就是使用fbo进行一次图像纹理转换。传入参数为屏幕方向、摄像头方向和渲染尺寸。
目前产品实现了左右移、上下移、拉近拉远、顺时针逆时针旋转等几种转场效果。转场的实现方法是：对于两个在其中添加了转场的素材，在上一个素材的最后1000ms绘制转场滤镜，转场滤镜即将两张图片的像素以一定的规律进行渲染，转场算法由opengl使用glsl着色器实现。转场基类的片元着色器如下，移动转场（左右向移动和上下移动）、缩放转场（拉近拉远）、旋转转场对getFromColor与getToColor执行的行为不同。
以移动转场的转场glsl着色器为例
转场的具体实现参考了GPUImageFilter库，和美颜滤镜以及文字贴纸不同的是，转场滤镜需要在渲染前预先设置将下个素材的首帧图。
在预览编辑过程中，由于音乐并不需要真正合成于视频中，因此可以使用另一个播放器单独播放音频，我们采用android更原始的MediaPlayer单独播放音乐，单独支持音乐的裁剪播放和seek。
抽帧预览即每隔固定时间取视频的一帧图片构成时间轴，我们使用ffmpegMediaMetadataRetriever库进行抽帧 ，使用方法为
该库内部使用ffmpeg进行解码取帧，接口易用但是其软件解码方式效率过低，相对较慢。因为exoplayer播放器是默认使用硬件解码的，可以采用另一个exoplayer播放器快速播放一次素材，然后每隔一段时间获取屏幕图像，但此种方法开销过大，两个exoplayer播放器不利于管理。
最后，我们发现常用的图片加载库glide也能进行视频抽帧，使用更为简单方便，其内部采用mediaMetadataRetriever进行抽帧。
1.调整素材，拼接、裁剪、变速
https://vod.cc.163.com/file/5f896ef25655da63cc2d3237.mp4
2.转场、文字贴纸、美颜滤镜
https://vod.cc.163.com/file/5f896edad70f81a0e3c77dbe.mp4
C. GPUImage（四）：你们处理的都是GPUImageFramebuffer类型
在使用GPUImage处理图片或者视频时，并不能直接对iOS官方定义的的UIImage、CGImage、CIImage进行操作。那么如果要使用GPUImage的话，第一步操作就是把你想处理的数据类型用一个GPUImage定义的载体承载，才能在GPUImage的处理链中进行一步一步的操作，这个载体就是GPUImageFramebuffer。我们把一张图像的像素等携带的全部信息看成好几种散装液体颜料的集合，系统提供了UIImage（最常用的图像类型）相当于一个颜料盒子，想把图片显示在iPhone设备屏幕上的话首先就是要把散装颜料装到这个颜料盒子里。GPUImageFramebuffer就是GPUImage中的颜料盒子，所以要先把UIImage盒子中的颜料倒到GPUImageFramebuffer中，才可以用GPUImage对这些颜料进行再次调色。调色的过程之前的文章中比喻成了一个多维度的管道，因此，在处理过程中就像GPUImageFramebuffer带着颜料在管子里流动，经过一个节点处理完后会有一个新盒子把调好色的颜料接住再往下流动。
从以上GPUImageFramebuffer.h的内容可看到，主要内容分为三大部分：1.framebuffer及texture的创建。2.GPUImage中GPUImageFramebuffer类型对象的内存管理。3.实际操作过程中数据存储的CVPixelBufferRef类型对象的具体操作。接下来就来看一下这三点中涉及到的具体类型到底是个啥以及在GPUImage框架中做了哪些事。
网络中对纹理的解释：
在大学时期有一门计算机图形课，主要是在Windows上使用C进行OpenGL开发。当时我做了一架直升飞机，虽然具体如何开发OpenGL现在已经有点陌生，但是其中印象非常深刻的有两个地方：1.只能画三角形，正方形是通过两个三角形组成的，圆形是有非常多个三角形组成的，三角形越多，锯齿越不明显。2.画好各种形状组成三维图形后可以往图形上面贴图，就好像罐头的包装一样，刚做好的罐头其实只是一个铝制或者其他材料制成的没有任何图案的圆柱体，出产前最后一道工序就是给罐头贴上一圈纸或者喷上相应的图案。最后出厂运往各个卖场，我才能买到印有“某巢”以及各个信息在罐子上的奶粉。纹理就是贴在上面的纸或者印在上面的图案。
纹理的WRAP设置解释如下（截图内容来自：http://blog.csdn.net/wangdingqiaoit/article/details/51457675）
字面上的意思是帧缓存，在OpenGL中，帧缓存的实例被叫做FBO。个人理解：如果texture是罐头上的内容，那framebuffer就是那张裹在罐头上的纸，它负责对纹理内容进行缓存并渲染到屏幕上，这个过程就叫做render to texture。当然framebuffer中不仅可以缓存原始的纹理内容，还可以是经过OpenGL处理后的内容。比如照片中牛奶罐头上除了有本身的名字、图案和说明这些内容，我们看上去还有相应的质感和反光效果，这个就可以通过获取反光中的实际影像进行透明、拉伸、雾化等效果处理后得到与实际反光一模一样的图，最终渲染到牛奶罐上。
从这个角度理解的话，可以把texture看作是framebuffer的一部分，因此在GPUImage中把指向texture的地址作为GPUImageFramebuffer的一个属性。当然也有不需要创建frambuffer的情况，比如在初始化输入源时例如GPUImagePicture类型对象，载入图片资源时只需要创建texture即可，GPUImageFramebuffer的其中一个初始化方法的其中一个参数onlyGenerateTexture为YES时，就可以只创建texture，把图片信息转化成纹理，而没有进行framebuffer的创建。
有创建就有销毁，GPUImageFramebuffer有一个私有方法- (void)destroyFramebuffer，在dealloc时调用。其中主要的操作是：
相信很多使用过GPUImage都会有同样的经历，都会遇到这个断言。以下就拿具体案例来解释GPUImage对GPUImageFramebuffer到底做了哪些事情。场景是：创建一个GPUImagePicture对象pic，一个GPUImageHueFilter对象filter和一个GPUImageView对象imageView，实现效果是pic通过filter处理后的效果显示在imageView上。具体的处理过程就不过多说明，我们来主要看一下GPUImageFramebuffer在整个处理过程中发生的情况。
·GPUImagePicture对象pic中的framebuffer
在对初始化传入的UIImage对象进行一系列处理后，pic进行自身的framebuffer的获取：
可以看到，framebuffer对象并不是通过初始化GPUImageFramebuffer来创建的，而是通过调用单例[GPUImageContext sharedFramebufferCache]的其中一个方法得到的。sharedFramebufferCache其实是一个普通的NSObject子类对象，并不具有像NSCache对象对数据缓存的实际处理功能，不过GPUImage通过单例持有这个sharedFramebufferCache对象来对过程中产生的framebuffer进行统一管理。获取framebuffer的方法有两个入参：1.纹理大小，在pic中的这个大小正常情况下是传入图片的初始大小，当然还有不正常情况之后再说。2.是否返回只有texture的的framebuffer对象。
第一步：
传入的纹理大小，textureOptions（默认）、是否只要texture调用sharedFramebufferCache的- (NSString *)hashForSize:(CGSize)size textureOptions:(GPUTextureOptions)textureOptions onlyTexture:(BOOL)onlyTexture;方法得到一个用于查询的唯一值 lookupHash。 由此可见如果纹理大小一致的GPUImagePicture对象获取到的lookupHash是相同的。
第二步：
lookupHash作为key，在sharedFramebufferCache的一个字典类型的属性framebufferTypeCounts获取到 ，如字面意思，在缓存中满足条件的GPUImageFramebuffer类型对象的个数。转换为整数类型为 numberOfMatchingTextures 。
第三步：
如果 小于1也就是没找到的话，就调用GPUImageFramebuffer的初始化方法创建一个新的framebuffer对象。否则：将lookupHash和（numberOfMatchingTextures - 1）拼接成key从sharedFramebufferCache的另一个字典类型的属性framebufferCache中获取到framebuffer对象。再更新framebufferTypeCounts中数值（减1） 。
第四步：
以防最后返回的framebuffer对象为nil，最后做了判断如果为nil的话就初始化创建一个。
第五步：
调用作为返回值的framebuffer对象的- (void)lock;方法。主要是对 framebufferReferenceCount 进行+1操作。framebufferReferenceCount为framebuffer的一个属性，初始化时候为0，作用也是字面意思：对象被引用的次数。此时需要进行+1操作是因为framebuffer对象即将被获取它的pic引用并将图片内容载入。
但是！与GPUImageFilter类型对象不同的是在pic获取到framebuffer后，进行了[outputFramebuffer disableReferenceCounting];。这个方法里将framebuffer的 referenceCountingDisabled 设置为YES。而这个属性的值在- (void)lock;方法中又会导致不一样的结果。如果referenceCountingDisabled为YES的话将不会对framebufferReferenceCount进行+1操作。
然而问题就出在这里 ，在pic获取到framebuffer之前，从sharedFramebufferCache找到framebuffer后就对它调用了- (void)lock;方法，此时pic获取到的framebuffer对象的framebufferReferenceCount已经被+1，而referenceCountingDisabled是在这之后才设置为YES，从而导致在pic对象dealloc时候自身的outputFramebuffer属性并未得到释放从而引起内存泄漏。为了解决这个问题我写了一个GPUImagePicture的caterogy，重写dealloc方法，将原本的[outputFramebuffer unlock];替换成 [outputFramebuffer clearAllLocks];， 保证outputFramebuffer的framebufferReferenceCount被重置为0，从而保证outputFramebuffer能顺利释放。
·GPUImageHueFilter对象filter中的framebuffer
我们以结构最简单的单输入源滤镜对象作为例子，通过GPUImageHueFilter对象filter。filter相比pic来说相同点是：自身都会通过sharedFramebufferCache获取到一个framebuffer用来存储经过自身处理后的数据并传递给下一个对象。不同点是：filter有一个 firstInputFramebuffer 变量，作用是引用上一个节点的outputFramebuffer。如果是继承自GPUImageTwoInputFilter的滤镜对象来说，它的成员变量将会多一个secondInputFramebuffer。若想进行到filter这，必须将filter作为pic的target，并调用pic的processImage方法。filter中方法调用顺序是：
1. 对输入的framebuffer引用并调用lock方法。假设pic的framebuffer为初始化创建的，传入前framebufferReferenceCount为1，经过此方法后framebufferReferenceCount则为2
2. filter的处理操作，也就是framebuffer的渲染纹理。这里就复杂了，那就不涉及到具体的渲染过程了。
filter的outputFramebuffer与pic一样，都是通过shareFramebufferCache查找获得。因此，outputFramebuffer变量被赋值时framebuffer的framebufferReferenceCount已经为1。接下来有一个判断条件： usingNextFrameForImageCapture 。在类中全局搜一下，发现在调用 - (void)useNextFrameForImageCapture; 方法时会将usingNextFrameForImageCapture设置为YES。那么什么时候会调用这个方法呢？有用GPUImage写过最简单的离屏渲染功能实现的都会觉得对这个方法有点眼熟，那就是在filter处理完后导出图片前必须要调用这个方法。为啥呢？原因就在这个判断条件这里，如果usingNextFrameForImageCapture为YES，那么outputFramebuffer要再lock一次，就是为了保证在处理完成后还需要引用outputFramebuffer，从而才可以从中生成图片对象，否则就被回收进shareFramebufferCache啦。
进行过一顿操作后，最后会调用输入源的unlock方法。这时候firstInputFramebuffer的framebufferReferenceCount按照正常情况的话将会为0，就会被添加到shareFramebufferCache中。
3. 接下来执行的方法中会把自身的outputFramebuffer传递给链中的下一个节点，就像pic到filter的过程一样。
这里的[self framebufferForOutput]在正常的filter中会返回outputFramebuffer。如果usingNextFrameForImageCapture为YES的话，可以简单理解当前对象的outputFramebuffer传递给下一个target后还有其他用处的话就不置空outputFramebuffer变量。如果usingNextFrameForImageCapture为NO的话，当前outputFramebuffer被置为nil，但是原先outputFramebuffer指向的framebuffer并不会被回收到shareFramebufferCache。原因是：framebuffer已经传递给下个target，在相应赋值方法中对framebuffer调用了lock方法。周而复始，直到最后一个节点，要么生成图片，要么显示。
D. 视频直播APP开发怎么做
一、直播的技术架构：
直播视频采集SDK（PC/IOS/Anddroid）——直播CDN
（直播流分发加速）——直播视频播放器SDK（PC/IOS/Android）
二、音视频处理的一般流程：
数据采集→数据编码→数据传输(流媒体服务器) →解码数据→播放显示
1、数据采集：
摄像机及拾音器收集视频及音频数据，此时得到的为原始数据
涉及技术或协议：
摄像机：CCD、CMOS
拾音器：声电转换装置（咪头）、音频放大电路
2、数据编码：
使用相关硬件或软件对音视频原始数据进行编码处理（数字化）及加工（如音视频混合、打包封装等），得到可用的音视频数据
涉及技术或协议：
编码方式：CBR、VBR
编码格式
视频：H.265、H.264、MPEG-4等，封装容器有TS、MKV、AVI、MP4等
音频：G.711μ、AAC、Opus等，封装有MP3、OGG、AAC等
3、数据传输：
将编码完成后的音视频数据进行传输，早期的音视频通过同轴电缆之类的线缆进行传输，IP网络发展后，使用IP网络优传输
涉及技术或协议：
传输协议：RTP与RTCP、RTSP、RTMP、HTTP、HLS（HTTP Live Streaming）等
控制信令：SIP和SDP、SNMP等
4、解码数据：
使用相关硬件或软件对接收到的编码后的音视频数据进行解码，得到可以直接显示的图像/声音
涉及技术或协议：
一般对应的编码器都会带有相应的解码器，也有一些第三方解码插件等
5、播放显示：
在显示器（电视、监视屏等）或扬声器（耳机、喇叭等）里，显示相应的图像画面或声音
涉及技术或协议：
显示器、扬声器、3D眼镜等
三、常见的视频直播相关协议：
1、RTMP(Real Time Messaging Protocol，实时消息传送协议)
RTMP是Adobe Systems公司为Flash播放器和服务器之间音频、视频和数据传输开发的开放协议。它有三种变种：
1）、工作在TCP之上的明文协议，使用端口1935；
2）、RTMPT封装在HTTP请求之中，可穿越防火墙；
3）、RTMPS类似RTMPT，但使用的是HTTPS连接；
RTMP协议是被Flash用于对象、视频、音频的传输。这个协议建立在TCP协议或者轮询HTTP协议之上。RTMP协议就像一个用来装数据包的容器，这些数据既可以是AMF格式的数据，也可以是FLV中的视音频数据。一个单一的连接可以通过不同的通道传输多路网络流，这些通道中的包都是按照固定大小的包传输的。
2、RTSP(Real Time Streaming Protocol，实时流传输协议)
RTSP定义了一对多应用程序如何有效地通过IP网络传送多媒体数据。RTSP提供了一个可扩展框架，数据源可以包括实时数据与已有的存储的数据。该协议目的在于控制多个数据发送连接，为选择发送通道如UDP、组播UDP与TCP提供途径，并为选择基于RTP上发送机制提供方法。
RTSP语法和运作跟HTTP/1.1类似，但并不特别强调时间同步，所以比较能容忍网络延迟。代理服务器的缓存功能也同样适用于RTSP，并且因为RTSP具有重新导向功能，可根据实际负载情况来切换提供服务的服务器，以避免过大的负载集中于同一服务器而造成延迟。
3、RTP(Real-time Transport Protocol，实时传输协议)
RTP是针对多媒体数据流的一种传输层协议，详细说明了在互联网上传递音频和视频的标准数据包格式。RTP协议常用于流媒体系统（配合RTCP协议），视频会议和一键通系统（配合H.323或SIP），使它成为IP电话产业的技术基础。
RTP是建立在UDP协议上的，常与RTCP一起使用，其本身并没有提供按时发送机制或其它服务质量（QoS）保证，它依赖于低层服务去实现这一过程。
RTP 并不保证传送或防止无序传送，也不确定底层网络的可靠性，只管发送，不管传输是否丢包，也不管接收方是否有收到包。RTP 实行有序传送，RTP中的序列号允许接收方重组发送方的包序列，同时序列号也能用于决定适当的包位置，如在视频解码中，就不需要顺序解码。
4、RTCP(Real-time Transport Control Protocol，实时传输控制协议）
RTCP是RTP的配套协议，为RTP媒体流提供信道外的控制。RTCP和RTP一起协作将多媒体数据打包和发送，定期在多媒体流会话参与者之间传输控制数据。
RTCP的主要功能是为RTP所提供的服务质量（QoS）提供反馈，收集相关媒体连接的统计信息，例如传输字节数，传输分组数，丢失分组数，单向和双向网络延迟等等。网络应用程序可以利用RTCP所提供的信息来提高服务质量，比如限制流量或改用压缩比小的编解码器。
E. android gpuimage 怎么使用
GPUImage 是iOS下一个开源的基于GPU的图像处理库，提供各种各样的图像处理滤镜，并且支持照相机和摄像机的实时滤镜。GPUImage for Android是它在Android下的实现，同样也是开源的，托管在Github上。
版本：android-gpuimage-1.1.1
Android模拟器上不支持OpenGL ES 2.0所以会报错，可以选用Genymotion测试，或真机上运行。
引用
Caused by: java.lang.IllegalStateException: OpenGL ES 2.0 is not supported on this phone.
(1)使用自定义的ImageView
Xml代码
<jp.co.cyberagent.android.gpuimage.GPUImageView
android:id="@+id/gpuimage"
android:layout_width="wrap_content"
android:layout_height="0dp"
android:layout_gravity="center"
android:layout_weight="1" />
Java代码
mImageView.setFilter(new GPUImageSepiaFilter()); // sepia
mImageView.setFilter(new GPUImageGrayscaleFilter()); // gray
mImageView.setFilter(new GPUImageSharpenFilter()); // sharp
mImageView.setFilter(new GPUImageSobelEdgeDetection()); // edge
F. 最简单的iOS直播推流如何使用GPUImage，如何美颜
视频直播，可以分为 采集，前处理，编码，传输，解码，渲染 这几个环节，下面分别说下： 采集，iOS是比较简单的，Android则要做些机型适配工作，PC最麻烦各种奇葩摄像头驱动，出了问题特别不好处理，建议放弃PC只支持手机主播，目前几个新进的直播平台都是这样的。 前处理，现在直播美颜已经是标配了，80%的主播没有美颜根本没法看。美颜算法需要用到GPU编程，需要懂图像处理算法的人，没有好的开源实现，要自己参考论文去研究。难点不在于美颜效果，而在于GPU占用和美颜效果之间找平衡。GPU虽然性能好，但是也是有功耗的，GPU占用太高会导致手机发烫，而手机发烫会导致摄像头采集掉帧，iPhone6尤其明显，因为iPhone6的CPU和前置摄像头很近。 编码，肯定要采用硬编码，软编码720p完全没希望，勉强能编码也会导致CPU过热烫到摄像头。硬编码兼容性又是一个大坑，android上要有人去填。编码要在分辨率，帧率，码率，GOP等参数设计上找到最佳平衡点。 传输，自己做不现实，交给CDN服务商吧，也就是贵了点，相信有志于做直播平台改变世界的你不差钱。假设2W PCU大约每月带宽费用100万左右，因为清晰流畅的720p要1.5mbps左右。CDN只提供了带宽和服务器间传输，发送和接收端的网络连接抖动缓冲还是要自己写的。不想要卡顿，必然要加大缓冲，会导致延迟高，延迟高影响互动性，要做权衡。 解码，也肯定要硬解码，目前手机普遍支持硬解了，只是android上还是有兼容性大坑要填。 渲染，这个难点不在于绘制，而在于音画同步，目前几个直播做得都不好。 此外音频还有几个坑要填，比如降噪，音频编码器的选择，各种蓝牙耳机，各种播放模式的适配等，如果你想做主播和观众连线聊天，还有个回声消除问题。 以上是媒体模块，还有信令控制，登录、鉴权、权限管理、状态管理等等，各种应用服务，消息推送，聊天，礼物系统，支付系统，运营支持系统，统计系统等。 后台还有数据库，缓存，分布式文件存储，消息队列，运维系统等。 第一期至少要融资2000万RMB，组建至少10人的技术团队，10人的产品运营团队，争取3个月产品上线，半年达到5W在线（2w 根本不够）然后融资1个亿，或许还有希望一搏。 这些对于创业者来说是一个难度系数非常大，创业初期还是建议接入第三方的直播SDK，可以节省成本，趣拍直播还是很不错的，不管是转码还是推流，支持1000多万人在线不卡顿，可以去了解下。 祝你朋友好运。
G. GpuImage 在Android 上的应用以及各种效果参照表
在布局中加上GPUImageView,为了显示处理后的图片载体
2：获取对应想要处理的效果Filter
3:通过Filter设置想要的效果展示出来
图片有点小，凑合着看吧
最后附上Android 最全的效果对应工具类：
项目github地址
H. IOS录制的视频在Android播放异常的问题
IOS使用GPUImage录制的视频默认是mov格式，如果直接转化为mp4，其实里面的文件编码还是mov，mov在Android上使用系统播放器表现为有视频没有音频，或者直接无法播放。
如果ios要和android同步上线，需要ios支持，转化为标准的mp4文件。这样android不仅能支持播放，还可以保存到相册让系统播放器播放。通过ffmpeg来编码是一种选择。
- 在iOS中使用FFmpeg命令
I. 怎么在github上开源ios代码
1. AFNetworking 在众多iOS开源项目中，AFNetworking可以称得上是最受开发者欢迎的库项目。AFNetworking是一个轻量级的iOS、Mac OS X网络通信类库，现在是GitHub上第三大Objective-C库。它建立在NSURLConnection、NSOperation等类库的基础上，让很多网络通信功能的实现变得十分简单，因此，许多iOS应用开发都会使用到它。 支持HTTP请求和基于REST的网络服务(包括GET、POST、PUT、DELETE等); 支持ARC; 要求iOS 5.0及以上版本; 有一些插件扩展已有的功能，还有一个功能齐全的API; 从URL中获取JSON特别简单。 2. Three20 Three20原本是iPhone版Facebook中所使用的工具库，包括照片查看器等一系列的iPhone UI类集，以及HTTP磁盘缓存等一些通用工具。后来从Facebook iPhone应用中剥离出来，成为了一个深受开发者喜爱的通用框架。 3. facebook-ios-sdk 此前在“GitHub上最受欢迎的开源项目”Android系列文章(一)中，我们曾介绍过允许开发者将Facebook集成到Android应用中的Facebook SDK for Android。Facebook SDK for iOS和它一样，可以让开发者将Facebook相关功能集成到自己的iOS App中。 Facebook无疑是最成功的SNS社区，如果能够让App具有与Facebook集成的功能，那势必会带来非常好的效果。Facebook SDK for iOS项目更新频率很高，想要获取更多关于示例、文档、将SDK集成到App中、源代码等信息，可直接登陆Facebook Developers查看。 4. RestKit Restkit是一个主要用于iOS上网络通信的开源Objective-C框架，除了发送请求、接受响应这些基本功能外，还附带Core Data，以及将远程JSON映射为本地对象的功能。 主要特点： 可在iOS和Mac OS X的Objective-C中与RESTful Web服务进行简单交互; 包含简单的HTTP Request/Response API; 带有强大的对象映射系统，用于减少代码长度; RestKit可降低JSON/XML的处理的资源消耗，支持通过SBJSON和YAJL进行JSON解析。 5. asi-http-request ASIHTTPRequest是一款极其强劲的HTTP访问开源项目，能够让简单的API完成非常复杂的功能，比如异步请求、队列请求、GZIP压缩、缓存、断点续传、进度跟踪、上传文件、HTTP认证。 ASIHTTPRequest适用于基本的HTTP请求，和基于REST的服务之间的交互。使用Objective-C编写，能够同时用于Mac OS X和iPhone应用中。 6. cocos2d-x 在《GitHub上最火的40个Android开源项目(一)》中，我们已经非常详细地介绍了cocos2d-x开源项目。cocos2d-x支持iOS、Android、Windows Phone 8、Bada、BlackBerry、Marmalade、Windows、Linux等多个平台。 7.cocos2d-iphone(cocos2d) cocos2d for iPhone是一个开源框架，用于为iPod Touch、iPhone、iPad及Mac OS X构建2D游戏、演示程序及其他图形交互式应用。基于cocos2d设计，使用相同的API，但不同于cocos2d使用Python，cocos2d for iPhone是使用Objective-C实现的。 cocos2d for iPhone主要特性： 快 免费 易于使用 社区支持 8.cocos2d-iphone(jpsarda) 该项目是对cocos2d for iPhone的扩展。 9. GPUImage GPUImage是一个基于GPU图像和视频处理的开源iOS框架。 主要功能如下： 提供各种各样的图像处理滤镜，并且支持照相机和摄像机的实时滤镜; GPUImage顾名思义，是基于GPU的图像加速，因此图像处理速度非常快，并且能够自定义图像滤镜; 支持ARC。 10. MonoGame MonoGame是一个Microsoft XNA 4.x Framework的开源跨平台实现。此前在Android开源项目系列文章(一)中我们也进行了详细的介绍。 MonoGame支持平台： iOS(包括Ritina Display) Android Windows(OpenGL) Mac OS X Linux Windows Store Apps(Windows 8、Windows RT) Windows Phone 8 PlayStation Mobile(目前仅支持2D) OUYA 11. Nimbus Nimbus是一个开源的iOS框架，比起Three20，Nimbus的文档更为全面、丰富，能够实现很多非常炫的界面特效。因此，开发者可以借助Nimbus来降低项目设计的复杂度。 12. cheddar-ios Cheddar是一个简单即时的任务管理器，Cheddar for iOS是Cheddar的iOS客户端，通用于iPhone和iPad。 13. ViewDeck IIViewDeckController能够实现类似于Path 2.0 的视图左右滑动的效果，支持向左或向右顺滑的滑动操作。 14. ShareKit ShareKit是iPhone开发的第三方接口，允许你一键分享文字、图片、网址、文件等内容到Facebook、Twitter、Delicious、Tumblr、Google Reader等第三方网站上。 15. GMGridView GMGridView是一款开源的iOS(iPhone/iPad)表格视图，允许用户手势对表格单元进行排序，在单元格需要展示时才进行装载，这样极大地提高了表格的效率。其中的伸缩/旋转/平移手势能够让用户改变视图，还能够实现从CellView到全屏的切换。 16. QuickDialog QuickDialog可以帮助开发者快速创建复杂的表单，实现包括登录界面在内的各种样式的TableView输入界面，此外，还可以创建带有多个文本域的表格及项目。 17. appirater Appirater是一个可以直接使用到任何iPhone应用(iOS4.0及以上)中的开源类，用于提醒用户在打开App时，对应用进行或打分。 18. SVProgressHUD SVProgressHUD能够实现多种HUD效果，多用于程序正在执行耗时较长的任务，需要用户等待。除了显示等待的HUD，还可以显示命令执行成功或者失败的HUD。 19. Reader 该项目能够让iOS开发者轻而易举地在iOS设备屏幕上显示PDF文件。代码通用，不需要任何XIB(因为所有UI元素都是代码生成的，具有极大的灵活性)，运行于iOS 4.0及其以上版本设备中，同时还支持所有Retina Display设备。 支持： 诸如iBooks等的文档导航; 设备全方位旋转; 对PDF进行加密(密码保护); PDF链接(URI及跳转页面); PDF旋转页面。 20.CocoaAsyncSocket CocoaAsyncSocket提供了十分强大而又易用的Mac OS X及iOS异步套接库，支持TCP和UDP，其中，AsyncSocket类是支持TCP的，AsyncUdpSocket是支持UDP的。 AsyncSocket是封装了CFSocket和CFSteam的TCP/IP socket网络库，提供异步操作。AsyncUdpSocket是UDP/IP socket网络库，包装自CFSocket。
J. 如何快速搭建一个完整的移动直播系统
移动直播行业的火热会在很长一段时间内持续，通过和各行业的整合，从而成为具有无限可能性的行业。主要因为以下三个原因：
第一，移动直播的UGC生产模式比PC端的直播更明显，人人都有设备，随时随地开播，完全顺应了互联网时代的开放性原则，能刺激更多人去创造和传播优质内容。
第二，网络带宽和速度在逐渐提高，网络成本在逐渐下降，为移动直播提供一个极佳的发展环境。文字、声音、视频、游戏等都会在移动直播中呈现，创造出更加丰富的用户体验。直播可以以SDK的形式接入到自己的应用中，比如，教育领域中的课后辅导完全可以以直播的形式开展业务、电商也可借助直播让用户挑选商品，促进销售。
第三，一个与VR/AR技术相结合的移动直播为整个行业的未来提供了新的发展空间。VR/AR直播能够让用户身临其境，带动主播与观众更贴切真实的互动，大大提高平台的用户参与度。
当下，有技术实力和流量优势的互联网从业者都不愿错过直播这个风口，如何快速搭建一个直播系统成了大家关心的问题，我想和大家分享下我的经验。我从事于一家直播产品开发商，我们的产品为了快速赶上市场，并没有自己完全去自己做，而是使用了趣拍云服务提供的直播SDK。
从业者都知道，一个完整直播产品应该包含以下环节：推流端（采集、前处理、编码、推流），服务端处理（转码、录制、截图、鉴黄），播放器（拉流、解码、渲染）、互动系统（聊天室、礼物系统、赞）。 下面我就一一讲述下直播SDK在各个环节所做的工作。
一、移动直播推流端需要做哪些工作？
直播推流端即主播端，主要通过手机摄像头采集视频数据和麦克风采集音频数据，经过一系列前处理、编码、封装，然后推流到CDN进行分发。
1、采集
移动直播SDK通过手机摄像头和麦克风直接采集音视频数据。其中，视频采样数据一般采用RGB或YUV格式、音频采样数据一般采用PCM格式。采集到的原始音视频的体积是非常大的，需要经过压缩技术处理来提高传输效率。
2、前处理
在这个环节主要处理美颜、水印、模糊等效果。美颜功能几乎是直播的标配功能。我们调研中发现太多case是因为没有美颜功能被抛弃使用的。另外国家明确提出了，所有直播都必须打有水印并回放留存15天以上。
美颜实际上是通过算法去识别图像中的皮肤部分，对皮肤区域进行色值调整。通过颜色对比找到皮肤区域，可以进行色值调整、添加白色图层或调整透明度等来等来达到美白效果。在美颜处理方面，最着名的GPUImage提供了丰富的效果，同时可以支持iOS和Android，支持自己写算法实现自己最理性的效果。GPUImage内置了120多种常见滤镜效果，添加滤镜只需要简单调用几行代码就可以了。
3、编码
为了便于手机视频的推流、拉流以及存储，通常采用视频编码压缩技术来减少视频的体积，现在比较常用的视频编码是H.264。在音频方面，比较常用的是用AAC编码格式，其它如MP3、WMA也是可选方案。视频经过编码压缩大大提高了视频的存储和传输效率，当然，经过压缩后的视频在播放时必须进行解码。
相较于之前的H.264，2012年诞生的H.265编解码标准有了相当大的改善，做到了仅需要原来一半带宽即可播放相同质量的视频，低于1.5Mbps的网络也能传输1080p的高清视频。像阿里云、金山云都在推自己的H.265编解码技术，随着直播的快速发展和对带宽的依赖，H.265编解码技术已有全面取代H.264的趋势。
H264和H265个模块技术差异：
另外，硬件编码已经成为移动直播的首选方案，软编码处理在720p以上的视频颓势非常明显。在iOS平台上硬件编码的兼容性比较好，可以直接采用，但在 Android 平台上，MediaCodec 编码器针对不同的芯片平台表现差异还是非常大的，要完全实现全平台兼容的成本还是非常高的。
4、推流
要想用于推流还必须把音视频数据使用传输协议进行封装，变成流数据。常用的流传输协议有RTSP、RTMP、HLS等，使用RTMP传输的延时通常在1–3秒，对于移动直播这种实时性要求非常高的场景，RTMP也成为移动直播中最常用的流传输协议。最后通过一定的Qos算法将音视频流数据推送到网络断，通过CDN进行分发。在直播场景中，网络不稳定是非常常见的，这时就需要Qos来保证网络不稳情况下的用户观看直播的体验，通常是通过主播端和播放端设置缓存，让码率均匀。另外，针对实时变化的网络状况，动态码率和帧率也是最常用的策略。
当然，在网络传输方面全部自己来做基本不现实，找提供推流服务的CDN服务商提供解决方案是最好的选择，可参考文章开头介绍的云视频服务商。据了解，阿里云是国内唯一能自研CDN缓存服务器的厂商，性能非常有保障。当然，大多数直播平台都会同时接入多个视频云服务提供商，这样可以做拉流线路互备，对推流后视频集群再进行优化也可提高直播的流畅性和稳定性。
二、服务端处理需要做哪些工作？
要想适配各终端和平台，服务端还需要对流进行转码，如支持RTMP、HLS、FLV等格式拉流，支持一路转多路适配不同网络和分辨率的终端设备。
1、截图、录制、水印
像阿里云等云服务商都提供了实时转码技术，将用户推流码率较高（比如720P）实时转化成较低清晰度（比如360P）的流以适应播放端的需求。如果要自己搭建实时转码系统，这个成本是极高的，一台8核设备只能实时转10路流，如果一个正常的直播平台有1000路流，就需要100台设备，加上后期的运维成本，一般公司就吃不消了。
2、鉴黄
2016年4月14日，文化部查出了斗鱼、虎牙、YY、熊猫TV、六间房、9158等涉嫌提供含宣扬淫秽、暴力、教唆犯罪的网络直播平台，被列入查处名单。政府介入管制有利于直播行业打造健康的生态，进入良性发展。这也意味着为了安全直播产品鉴黄成了必需环节，使用技术手段去鉴黄是移动直播平台必然采用的方案。
市面上提供鉴黄服务的方案主要有两种，第一种是对视频进行截图，然后对图片进行鉴黄，返回鉴黄结果和分值。典型的企业有阿里（绿网）、图谱科技，他们目前都支持直接传入视频，经过服务端分析返回结果。通常由业务系统接入鉴黄服务，根据鉴黄结果对直播流进行控制，如切断直播流、封禁账号等。第二种是和CDN结合，直接对直播流进行分析，识别结果分为色情、疑似色情、性感和正常，业务系统根据识别结果直接控制直播流。典型的企业是Viscovery，这套方案的优点是实时性保证比较好，缺点是必须部署到CDN或自己的机房，使用成本相对高一些。
还有像趣拍云服务这种一站式直播解决方案提供商，他们的做法是，用户只需在控制台对鉴黄服务进行配置就可以针对每个应用、每一路直播流进行实时审核。在控制台中，趣拍视频云服务实时将鉴黄结果返回，用户可以直接查看色情直播和违规界面的截图，同时可以对直播流进行控制，切断问题直播流。该服务商还提供了短信、邮件和站内信功能，避免漏掉任何一个非法视频，给平台造成损失，我们就使用了这种方式。
三、播放器端需要做哪些工作？
在播放器端如何做到秒开，直播过程中保证画面和声音清晰度的同时，稳定、流程、无卡顿的直播流量，这些工作都需要播放器端配合服务端来做优化，做到精确调度。
1、拉流
拉流实际是推流的逆过程。首先通过播放端获取码流，标准的拉流格式有RTMP、HLS、FLV等。RTMP是Adobe的专利协议，开源软件和开源库都支持的比较好，如开源的librtmp库，播放端只要支持flashPlayer的就能非常简单的播放RTMP直播，直播延迟一般在1–3秒。HLS是苹果提出的基于HTTP的流媒体传输协议，HTML5可以直接打开播放，通过微信、QQ等软件分享出去，用户也可以直接观看直播，可以说移动直播app，HLS拉流协议是必须支持的，缺点是延迟通常大于10秒。FLV（HTTP-FLV）协议是使用HTTP协议传输流媒体内容的一个协议，也不用担心被Adobe的专利绑架，直播延迟同样可以做到1–3秒。
各拉流协议的差异：
我们使用的趣拍视频云服务的直播拉流技术提供了以上三种格式，满足不同业务场景的需求，如对即时性要求较高或有互动需求的可以采用RTMP或FLV格式进行直播拉流播放；对于有回放或跨平台需求的，推荐使用HLS。当然，三种协议是可以同时使用的，分别用到自己的场景就可以了。
2、解码和渲染
拉流获取封装的视频数据后，必须通过解码器解码、渲染后才能在播放器上播放。它是编码的逆过程，是指从音视频的数据中提取原始数据。前面介绍的H.264和H.265编码格式都是有损压缩，所以在提取后的原始数据，并非原始采样数据，存在一定的信息丢失。因此，在视频体积最小的情况下通过各种编码参数保留最好的原始画面，成为了各视频公司的核心机密。
考虑对高清的支持，解码肯定还是要选择硬解码的。前面介绍过，iOS系统由于硬件比较单一、比较封闭，支持的比较好，Android系统由于平台差异非常大，编解码要完全兼容各平台还需要很多工作要做。
四、移动直播中的交互系统
移动直播中最常见的交互有聊天室（弹幕）、点赞、打赏和礼物等，交互系统涉及消息的实时性和互动性，在技术实现上大多是使用IM的功能来实现的。对于在线人数比较多的房间，弹幕消息量是非常大，主播与用户其实都看不过来，为了缓解服务器压力，在产品策略需要做一些必要的优化。
1、聊天室
移动直播中的弹幕交互是用户和主播互动的主要方式，实际上就是IM中的聊天室功能。聊天室和群聊功能类似，但聊天室的消息是不需要分发给不在线的用户的，历史消息也不需要查看，用户只有进入聊天室后才能查看聊天消息和群成员信息。面对复杂多变的网络状况，还需要根据用户位置就近选择近对应运营商的单线机房接入弹幕消息服务，让弹幕更及时。
2、礼物系统
礼物系统更是绝大多数移动直播平台的标配了，它是这些平台主要的收入来源。送礼物的形式也增强了用户和主播之间的互动交流，也是主播依赖平台的最主要原因。
礼物的收发在技术实现上也是用聊天室接口做的，通常采用IM中的自定义消息实现，当用户收到或发送礼物时将自定义消息对应的礼物图形渲染出来。
以上就是我们在使用了第三方SDK服务后总结出来的直播产品经验，希望能帮助到创业者和从业者们。
蒋先生（微信号love-drunk-hard），直播行业老兵。