如何在C＃中捕捉视频而不牺牲性能?
 

 
从Tilt Brush捕捉的4x超级采样渲染。 Sarah Northway绘制的“Space Dragon”


在引擎中截取视频或屏幕截图，对游戏或图形应用程序来说是很好的分享功能，对于错误报告、社交分享或跟踪开发进度来说也很有帮助。 在Unity中，直接从游戏中截取视频帧不难办到。 然而，一个易于使用的API同时肩负重任。 对于那些开发VR内容并希望提供良好用户体验的人们来说，保持良好的性能是关键所在。

本文将说明如何仅使用C＃和Unity API实时截取合适的《Tilt Brush》视频的同时，保持实现舒适的VR体验所需的90Hz高刷新率。

我们使用自制的原生插件实现了该功能，但在实现原生插件之前，先尝试了解决C＃API中的问题。  

下面是社区使用《Tilt Brush》6.0中的视频截取相机制作的视频：


社区创建的内容：3Donimus绘制的“Forest Elf”
音乐来自Kevin MacLeod


在Unity中捕捉帧缓冲区需要使用RenderTexture和Texture2D。 之后复制像素很容易。

初级方法：

[C#] 纯文本查看 复制代码
?
// 设置相机、纹理及RenderTexture
Camera cam = ...;
Texture2D tex = ...;
RenderTexture rt = ...;
// 渲染到RenderTexture
cam.targetTexture = rt;
cam.Render();
// 读取像素到纹理
RenderTexture.active = rt;
tex.ReadPixels(rectReadPicture, 0, 0);
// 读取纹理到数组
Color[] framebuffer = tex.GetPixels();


完成！每帧执行性能也很好！但这种做法在VR体验中不可行。

该过程运行慢的基本原因如下：

  • GetPixels() 阻塞直到 ReadPixels() 完成
  • 刷新GPU时， ReadPixels() 阻塞
  • 每次调用GetPixels()都会分配一个新数组，垃圾回收器导致卡顿


在ReadPixels()和GetPixels()之间设置一帧的延迟就可以避免第一个问题，任何类型的传输都将在需要访问这些值之前完成。

比较麻烦的是ReadPixels()会导致GPU刷新。 这是什么意思？

当向GPU发出命令/绘制调用时，这些命令会被批处理到驱动程序中的批量命令缓冲区中。 “刷新GPU”意味着等待当前命令缓冲区中的所有命令执行。 CPU和GPU可以并行运行，但在GPU刷新时，CPU会保持空闲状态并等待GPU空闲，这就是它被称作“同步点”的原因。为什么会发生这种情况？

如果使用NVIDIA的Nsight等性能分析工具，跟踪Unity对DirectX的使用，会发现ReadPixels()是通过调用CopySubresourceRegion后紧接着调用Map和Unmap来实现的。 Map读取CopySubresourceRegion结果很高效。

正如DirextX文档所说，GPU复制可以流式进行，并且与CPU同时执行。 但如果在复制完成之前请求数据，则唯一返回同样值的方法就是完成所有待处理命令，从而强制CPU-GPU同步。

从Nsight性能图中可以明显看到这种情况：
 

 
CPU-GPU同步5毫秒


上图表示Unity API在强制同步，这个比较慢。由于我们知道这会强制同步，可能某些时候同步的开销较小。如果GPU已经是空闲状态呢？ 然后同步时间应该仅限于传输成本，这将远远小于等待所有或部分帧渲染完成所需的时间。

在本例中，SteamVR也会强制同步，因此在某个点GPU是空闲的。这需要对渲染引擎有深入了解，类似Nsight的Frame Debugger或RenderDoc工具可以帮助探索黑盒中发生的事情。

OnPreRender()看起来可靠，但是从下图中可以看出，该方法仅轻微提高了性能，然而在开始传输之前，CPU仍然会阻塞以等待某些任务完成：
 

 
CPU-GPU同步2毫秒


这台相机不是场景中唯一的相机，因此GPU在OnPreRender()期间不一定处于空闲状态。

我们知道SteamVR会强制同步，可以在SteamVR渲染循环协程中插入一个回调到自己的代码来复制像素。但测试之后还是2毫秒的同步，与之前截图一样。

深入框架底层跟踪发现有一个早期的深度通道、阴影通道等。额外的相机才是真正的问题所在。 视频捕捉相机是在SteamVR渲染循环之外渲染的由于渲染循环实现了运行启动算法，所以额外的相机既搞乱了运行启动，也导致了GPU完全没有空闲时间。

最后我们将额外的渲染和像素复制都移至SteamVR渲染循环中完成，在下面的截图中，同步时间已经减少到只与传输相关：
 

 
CPU-GPU同步0.5毫秒


最终的事件序列如下：

  • 渲染帧
  • Blit转为Render Texture作为后期效果
  • 帧结束
  • 在SteamVR渲染循环中，将Render Texture复制到Texture2D
  • 在SteamVR渲染循环中，渲染第二个相机
  • 等待一帧
  • 在SteamVR渲染循环中，复制纹理Bit到C#中


请注意，我们需要三帧来实现该技术（对于90Hz的显示屏，截屏限制为30FPS），然而如果您的应用没有内存限制，这些步骤也可以流式进行。

现在减少了与GPU中待处理任务量成比例的同步时间，该时间仅与截取的像素数量以及PCle总线的速度有关。

此时这种实现仅有0.5毫秒的消耗（每帧预算的5%），这在可接受范围内。将像素复制回C#还有额外的CPU消耗，总消耗约为3毫秒。这已达到每帧预算的30%，但我们已经预留了用于运行截屏的成本，因为开始运行后CPU可能是空闲的。

但每隔20帧左右还是会出现卡顿。查看Unity Profiler发现GC会出现一些峰值，每个大概12毫秒：
 

 
Profiler显示垃圾回收消耗12.73毫秒


这时需要回头查看GetPixels()，每次调用该函数都会分配内存并将内存移交给调用者。这些内存不能在下次调用GetPixels()时重用，因此每次帧截取都会生成堆内存垃圾，然后根据帧缓冲区的大小，每隔20帧左右被回收。

如果每帧执行垃圾回收会产生重大消耗（例如寻找根节点等），这不仅仅关乎于垃圾大小，还与分配的内存有关。不过，这确实将消耗减少到了7毫秒（帧预算的70%），但是依旧很慢。

有个很大胆的想法：如果垃圾回收是线程安全的，也许就能在后台线程运行，从而避免阻塞主渲染线程。实际上垃圾回收是线程安全的，但渲染线程分配任何内存，都会再次阻塞。本例中，Unity是唯一需要分配内存的一方，所以该方案可行！目前不足的地方就是垃圾回收的消耗。

最后应用了模糊和花絮的后处理特效以匹配此前宣传片中的风格。另外，2倍超采样用于视频，4倍超采样用于制作高清内容进行分享。至于超采样的消耗，截取视频时头显设备的分辨率会下降。

锐亚教育锐亚教育微信公众号