GPUImage详细解析（十三）多路视频绘制

前言

最近做多路视频的渲染，本文是其渲染方案的预研。
效果大概如下：

效果图

正文

一、多GPUImageView方案

用GPUImage进行多路视频的渲染，有一个非常简单的方案：多个GPUImageView方式，每路视频画面单独渲染。
一路视频对应一个滤镜链，拿到视频数据后进行裁剪，直接显示到对应的GPUImageView上；多个GPUImageView组成多路视频画面，通过改变GPUImageView的坐标可以实现画面拼接的效果。

方案很简单，写了一个demo，地址在这里。
demo用两个mp4视频作为源数据，用GPUImageMovie作为滤镜链的起始，用GPUImageCropFilter对视频进行裁剪，再经过GPUImageTransformFilter转置，最终显示在GPUImageView上。
这个方案的优缺点也很明显：
优点：实现简单，画面拼接由UIKit层的API实现；
缺点：渲染到屏幕的次数增多，渲染频率远大于屏幕显示帧率；

二、单GPUImageView方案

上面的方案最明显的问题就是渲染到屏幕的次数比屏幕刷新的次数还多，那么自然延伸出来一种方案：只用一个GPUImageView，视频统一渲染到GPUImageView。
GPUImageView显示区域划分成多个区域，每个区域对应一路视频；多路视频画面都采用离屏渲染的方式，绘制到纹理的对应区域中，再由multiTexFilter进行处理；multiTexFilter集合多路视频的渲染，如果没有更新则使用上次的数据，再把纹理传递给GPUImageView，最终GPUImageView渲染到屏幕上；

方案较为复杂，同样实现了demo，地址在 这里。
demo用两个mp4视频作为源数据，仍然用GPUImageMovie作为滤镜链的起始，再经过GPUImageCropFilter、GPUImageTransformFilter处理，交给LYMultiTextureFilter，最终显示在GPUImageView上。
此方案的核心在于LYMultiTextureFilter类，我们来仔细分析下其构成：

/**
 把多个Texture渲染到同一个FrameBuffer
 
 使用时需要先绑定frameBuffer和显示区域rect
 在newFrame回调的时候，会根据index把图像绘制在绑定的rect
 特别的，会制定一个mainIndex，当此index就绪时调用newFrame通知响应链的下一个
 */
@interface LYMultiTextureFilter : GPUImageFilter

- (instancetype)initWithMaxFilter:(NSInteger)maxFilter;

/**
 设置绘制区域rect，并且绑定纹理id

 @param rect 绘制区域 origin是起始点，size是矩形大小；（取值范围是0~1，点(0,0)表示左下角，点(1,1)表示右上角, Size(1,1)表示最大区域）
 
 @param filterIndex 纹理id
 */
- (void)setDrawRect:(CGRect)rect atIndex:(NSInteger)filterIndex;

- (void)setMainIndex:(NSInteger)filterIndex;

LYMultiTextureFilter继承自GPUImageFilter，通过-setDrawRect绑定纹理的绘制区域；特别的，可以设置一个mainIndex，当此index就绪时调用newFrame通知滤镜链的下一个目标。
具体实现有几个注意事项：
1、通过顶点指定特别的渲染区域；
2、因为GPUImageFramebuffer默认会被复用，导致无法保存上一次的纹理，这里需要修改逻辑-renderToTextureWithVertices:和-informTargetsAboutNewFrameAtTime，使得LYMultiTextureFilter一直使用同一个GPUImageFramebuffer；
3、dealloc的时候需要释放outputFramebuffer，避免内存泄露；

这个方案的特点：
优点：统一渲染，避免的渲染次数大于屏幕帧率；
缺点：multiTexFilter实现复杂，画面拼接需要用shader来实现；

三、两个方案的对比

通过对比两个方案的CPU、GPU占比，分析性能。

CPU对比：如下。选中前30s的区间，singleImageView的方式有0.5s(大概2%）的微弱优势。整个过程的cpu消耗波形类似，占比也大致相同。

GPU对比：方案1的GPU消耗比方案2的消耗更小！！！
难以置信，因为方案2是对方案1的优化，但是为何会占用更多的GPU？
通过instruments工具查看，方案1的presentRenderBuffer调用次数超过每秒100次，方案2在30次左右。
回顾方案1的设计：
GPUImageMovie => GPUImageCropFilter => GPUImageTransformFilter => GPUImageView
方案2的设计：
GPUImageMovie => GPUImageCropFilter => GPUImageTransformFilter => LYMultiTextureFilter => GPUImageView
方案2滤镜链比方案1多了LYMultiTextureFilter，虽然调用presentRenderBuffer的次数少，但是明显离屏渲染变多。相反，因为多LYMultiTextureFilter这个路径，导致总的gl渲染指令变多，GPU消耗更大！！
究其原因，是因为作为数据源GPUImageMovie是不同步的。即使是方案2，多个GPUImageMovie的数据输出也是不同步，渲染给LYMultiTextureFilter的次数同样可能出现大于使用次数的情况。方案2相对方案1，同样存在多余的渲染问题。
于是有了进一步优化的方案。

四、屏幕帧率驱动的单GPUImageView方案

先看一张大图：

相对于之前的方案，这里引入CADisplayLink作为渲染的驱动，同时视频数据只保持最新的一帧。如果每个cropFilter都能驱动multiTexFilter渲染，则multiTexFilter的渲染频率最高会达到120FPS，浪费性能。
为了保证multiTexFilter绘制的帧率不超过30FPS，cropFilter渲染顺序是1~N，最后以cropFilterN 作为multiTexFilter渲染的驱动。
当cropFilterN渲染完，就进行multiTexFilter的渲染，如果其他cropFilter没有数据则使用上一帧数据。
cropFilter在渲染的时候从DataManager取数据，如果没有数据则使用默认数据进行渲染。

为了方便对比，同样实现了demo，地址在这里。
与方案2相比，有几个不同点：
1、CADisplayLink驱动渲染，并且每次只读取当前最新帧；
2、引入LYAssetReader，LYAssetReader是对AVAssetReader和AVAssetReaderTrackOutput的简单封装，使得能循环播放和读取当前最新的视频帧；
3、使用GPUImageMovie的-processMovieFrame接口作为滤镜链的输入；
4、可以控制每次渲染中，cropFilter的渲染顺序；

综合考虑，暂定方案3--屏幕帧率驱动的单GPUImageView方案作为生产环境的渲染方案。

五、Demo实现过程的坑

1、帧缓存复用

有段时间没有接触GPUImage，导致demo开发过程遇到几个坑，首先第一个是如何保证画面渲染的连续。
在实现方案2的demo时，考虑到多路视频渲染中可能某一路的视频画面没有更新，比如说GPUImageMovie读取视频源数据较慢，此时GPUImageMovie对应的显示区域就无法redraw，导致该区域的内容显示异常，出现闪烁的效果。（GPUImage的帧缓存是复用的）
这里有两种方案：
1、保留GPUImageMovie读取的最后一帧信息，每次再传给cropFilters进行渲染；
2、保留cropFilters上一次的渲染结果；
从性能优化的角度出发，保留上一次的渲染结果更为合理。
这里的实现需要对GPUImage以及OpenGL有所了解，保留渲染结果其实就是复用上一次的帧缓存，不调用glClear进行清理；而GPUImage的outputFramebuffer在渲染完后会回收，所以需要一些修改，如下：

    if (!outputFramebuffer) {
        outputFramebuffer = [[GPUImageContext sharedFramebufferCache] fetchFramebufferForSize:[self sizeOfFBO] textureOptions:self.outputTextureOptions onlyTexture:NO];
        glClearColor(backgroundColorRed, backgroundColorGreen, backgroundColorBlue, backgroundColorAlpha);
        glClear(GL_COLOR_BUFFER_BIT);
    }
    else {
        [outputFramebuffer lock];
    }

仅在第一次的时候，为outputFramebuffer申请缓存；以后再次使用的时候，只需要进行lock即可。
这里有一个坑：GPUImageContext的fetchFramebufferForSize会默认进行一次lock，在使用完之后会再unlock；如果在第二次使用outputFramebuffer的之后不进行lock，会导致retainCount<0的情况。

2、GPUImageMovie处理CMSampleBuffer

另外一个较大的坑是GPUImageMovie，方案3的Demo在实现过程中遇到一个必现Crash：在调用GPUImageMovie的-processMovieFrame 处理从视频帧读取的CMSampleBuffer时，会在convertYUVToRGBOutput的glDrawArrays报错，错误类型是EXC_BAD_ACCESS，具体关键词是"gleRunVertexSubmitARM"。
怀疑过纹理有异常、顶点数据有异常、处理线程不统一等导致，均不是原因。

最后通过二分大法，插入以下代码定位到问题：

{
                GLenum err = glGetError();
                if (err != GL_NO_ERROR) {
                    printf("glError: %04x caught at %s:%u\n", err, __FILE__, __LINE__);
                }
            }
}

问题的核心在于GPUImageMovie *imageMovie = [[GPUImageMovie alloc] init];
GPUImageMovie的convertYUVToRGBOutput需要用到数据在initWithUrl:这个接口才有初始化！

总结

通过分析，我们可以发现三个方案各自的应用场景。
demo代码量不大，却是对GPUImage的灵活应用，可以很好的检验OpenGL ES学到的知识。
OpenGL ES还不太了解的请点击OpenGL ES文集。