[macOS/iOS] Capture from MSAA texture results in black video frames
Unity version
Unity 6000.2.5f1
Unity editor platform
macOS
AVPro Movie Capture edition
Full
AVPro Movie Capture Version
5.3.4
Xcode version being used to build your Unity project.
26.0.1 but same issue on 18 versions
Which iOS version(s) are you using?
26.0.1 but same issues on 18 versions
Hardware
iPhone 17, 16, 15
Which capture component are you using?
Capture From Screen
Capture mode
Realtime
Which output mode are you using?
Video file
Video codecs
HEVC
Audio source
Microphone
Audio codecs
AAC
Any other component configuration
We have also tried with H264 codec. This was working prior to the Unity upgrade and we have confirmed it is still working with Unity 6000.0.47f1 with the same iOS and Xcode versions (26.0.1).
The issue
We are using Unity and AVPro Movie Capture (the latest 5.3.4 released in June 2025) to record video on iOS. We are running the latest version of IOS, 26.0.1 (18 has the same issue) and we recently updated to Unity 6000.2.5f1 from 6000.0.47f1. On 6000.0.47f1 we were able to record video using Screen Capture without any issues, but now, on 6000.2.5f1 on device (in Editor seems to still be OK) while the length looks correct and we are capturing audio the video is completely black.
I tried using the H264 and HEVC codecs (but not the other option which is MJPEG) and both had the same issue. I confirmed that Texture Capture, creating a single PNG is still OK, and Camera Capture seems to be OK as well. While switching the main recording function to Camera Capture is possible it would lose some post processing effects that are applied after the camera generates the render texture.
Log output
When running with Xcode no relevant errors are logged
Actually this is happening with both Camera Capture and Screen Capture. Only Texture Capture is working.
So the only difference is that you changed Unity version? If you open a new project in Unity 6000.2.5f1 and just run the AVPro Movie Capture demo scenes, does the issue still occur?
We can't reproduce this on our end using: Unity 6000.2.6f2 iPhone 13 Pro, iOS 26.0.1 Screen Capture Demo
Yes, updating the Unity version was the only change, although Unity does recompile the shaders. We are also running on iOS 26.0.1 and do not have any issues with recording in the Editor.
Also, it seems to be primarily (or exclusively) camera capture -- I may have been mistaken about screen capture, but I haven't had a chance to reverify that, apologies if I led you down a bad testing path.
However, I have traced the issue, or at least the blocking issue, to MSAA. These were the errors / assertions I was eventually able to find:
-[MTLDebugRenderCommandEncoder validateCommonDrawErrors:]:5970: failed assertion `Draw Errors Validation Fragment Function(fragTexturedQuad): incorrect type of texture (MTLTextureType2DMultisample) bound at Texture binding at index 0 (expect MTLTextureType2D) for texture0[0].
' -[MTLDebugRenderCommandEncoder validateCommonDrawErrors:]:5970: failed assertion `Draw Errors Validation Fragment Function(fragTexturedQuad): incorrect type of texture (MTLTextureType2DMultisample) bound at Texture binding at index 0 (expect MTLTextureType2D) for texture0[0].
' Can't show file for stack frame : <DBGLLDBStackFrame: 0x361c3a7b0> - stackNumber:15 - name:::InsertCustomMarkerCallback(). The file path does not exist on the file system: /Users/bokken/build/output/unity/unity/Runtime/GfxDevice/GfxDevice.cpp
This was an AI analysis -- I don't know if accurate:
Metal (iOS/macOS) is validating a draw call. The shader fragTexturedQuad expects a 2D texture (MTLTextureType2D). Instead, Unity/AVPro is binding a multisampled RenderTexture (MTLTextureType2DMultisample). Metal refuses to run the draw because the texture type doesn’t match the shader’s expectation. So: AVPro (or Unity’s blit path) is trying to sample from a multisampled RT as if it were a normal 2D texture.
In your CaptureFromCamera code, AVPro creates a temporary RenderTexture for capture:
_target = RenderTexture.GetTemporary(width, height, 24, textureFormat, RenderTextureReadWrite.Default, aaLevel); Notice the last parameter: aaLevel. If anti‑aliasing is >1, Unity creates a multisampled RT.
Later, when AVPro blits that RT into its resolve/shader pipeline, Metal complains because the shader expects a non‑MSAA texture.
In Unity 6000.0.47f1, Unity may have been more lenient (auto‑resolving MSAA → 2D). In 6000.2.5f1, Metal’s validation is stricter, so you now see the assertion.
Based on this, I changed the Anti-aliasing dropdown from Current to None -- we have several render target settings, some of which use aa some do not and we were recording with one of those with aa on. By forcing it to none we are able to get normal recordings again.
I don't know if this is an actual error in the texture / shader, or maybe the conversion process during the update -- I did try and reinstall AVPro again after the update, but I didn't fully delete it first so I'm not sure it actually overwrote the previous updated version.
Same happens if you change anti-aliasing on URP rendering settings. I had to go over all the settings to find this out.
MSAA: OFF
MSAA: 2X
I didn't try it on mobile yet. This is straight from editor.
Based on this, I changed the Anti-aliasing dropdown from Current to None -- we have several render target settings, some of which use aa some do not and we were recording with one of those with aa on. By forcing it to none we are able to get normal recordings again.
I’m experiencing the same issue on macOS with Unity 6000.0.58f2 and 6000.0.60f1. @genereddick’s workaround fixed it for me as well. Thanks a lot!
FYI, I don't use CaptureFromCamera. I use CaptureFromTexture and I create my RenderTexture by myself.
I was using GetCameraAntiAliasingLevel but now just assigned 1 now.
- int aaLevel = capture.GetCameraAntiAliasingLevel(Camera.main);
- var renderTexture = RenderTexture.GetTemporary(res.x, res.y, 24, textureFormat, RenderTextureReadWrite.Default, aaLevel);
+ var renderTexture = RenderTexture.GetTemporary(res.x, res.y, 24, textureFormat, RenderTextureReadWrite.Default, 1);
Works fine with the change above.
I think GetCameraAntiAliasingLevel fails to get the actual antialiasing level in every render pipeline.
The required MSAA resolve wasn't happening (not sure when this changed) but has now been implemented. The fix will make it into the next release (version 5.3.5).