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

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

完成！每帧执行性能也很好！但这种做法在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性能图中可以明显看到这种情况：

 

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

在本例中，SteamVR也会强制同步，因此在某个点GPU是空闲的。这需要对渲染引擎有深入了解，类似Nsight的Frame Debugger或RenderDoc工具可以帮助探索黑盒中发生的事情。
OnPreRender()看起来可靠，但是从下图中可以看出，该方法仅轻微提高了性能，然而在开始传输之前，CPU仍然会阻塞以等待某些任务完成：
 

这台相机不是场景中唯一的相机，因此GPU在OnPreRender()期间不一定处于空闲状态。
我们知道SteamVR会强制同步，可以在SteamVR渲染循环协程中插入一个回调到自己的代码来复制像素。但测试之后还是2毫秒的同步，与之前截图一样。
深入框架底层跟踪发现有一个早期的深度通道、阴影通道等。额外的相机才是真正的问题所在。 视频捕捉相机是在SteamVR渲染循环之外渲染的由于渲染循环实现了运行启动算法，所以额外的相机既搞乱了运行启动，也导致了GPU完全没有空闲时间。
最后我们将额外的渲染和像素复制都移至SteamVR渲染循环中完成，在下面的截图中，同步时间已经减少到只与传输相关：
 

最终的事件序列如下：

• 渲染帧
• 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毫秒： 

这时需要回头查看GetPixels()，每次调用该函数都会分配内存并将内存移交给调用者。这些内存不能在下次调用GetPixels()时重用，因此每次帧截取都会生成堆内存垃圾，然后根据帧缓冲区的大小，每隔20帧左右被回收。
如果每帧执行垃圾回收会产生重大消耗（例如寻找根节点等），这不仅仅关乎于垃圾大小，还与分配的内存有关。不过，这确实将消耗减少到了7毫秒（帧预算的70%），但是依旧很慢。
有个很大胆的想法：如果垃圾回收是线程安全的，也许就能在后台线程运行，从而避免阻塞主渲染线程。实际上垃圾回收是线程安全的，但渲染线程分配任何内存，都会再次阻塞。本例中，Unity是唯一需要分配内存的一方，所以该方案可行！目前不足的地方就是垃圾回收的消耗。
最后应用了模糊和花絮的后处理特效以匹配此前宣传片中的风格。另外，2倍超采样用于视频，4倍超采样用于制作高清内容进行分享。至于超采样的消耗，截取视频时头显设备的分辨率会下降。