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

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

 在引擎中截取视频或屏幕截图,对游戏或图形应用程序来说是很好的分享功能,对于错误报告、社交分享或跟踪开发进度来说也很有帮助。 在Unity中,直接从游戏中截取视频帧不难办到。 然而,一个易于使用的API同时肩负重任。 对于那些开发VR内容并希望提供良好用户体验的人们来说,保持良好的性能是关键所在。
本文将说明如何仅使用C#和Unity API实时截取合适的《Tilt Brush》视频的同时,保持实现舒适的VR体验所需的90Hz高刷新率。
我们使用自制的原生插件实现了该功能,但在实现原生插件之前,先尝试了解决C#API中的问题。  
Unity中捕捉帧缓冲区需要使用RenderTexture和Texture2D。 之后复制像素很容易。
初级方法:

// 设置相机、纹理及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倍超采样用于制作高清内容进行分享。至于超采样的消耗,截取视频时头显设备的分辨率会下降。