Hello! First, thank you for this incredible plugin. It is the only reliable way to get UVC capture cards working in Unity on Android.
I am developing a Mixed Reality application for the Meta Quest 3. Because I need to use Meta's Depth API for MR occlusion, Vulkan is strictly required (Meta has deprecated OpenGLES3 for modern MR features).
However, I am encountering a severe texture rendering bug specifically when using the Vulkan Graphics API.
Environment
Device: Meta Quest 3 (Horizon OS / Android 12L)
Unity Version: 6000
Plugin Version: r0.6.0
Scripting Backend: IL2CPP (ARM64)
Graphics API: Vulkan (Bug occurs) / OpenGLES3 (Works perfectly)
UVC Hardware: Hagibis USB-C Capture Card
Requested Resolution: 1920x1080 (PreferH264 = false, defaults to MJPEG)
Expected Behavior (OpenGLES3)
When forcing Unity to use OpenGLES3, the video feed renders flawlessly. The 1920x1080 image fills the RawImage texture exactly as expected, confirming that the UVC negotiation, permissions, and C# UVCDrawer logic are perfectly correct.
Actual Behavior (Vulkan)
When switching Unity to Vulkan, the video feed is squashed, cropped, and pushed into the corner of the texture.
Earlier versions of the plugin produced a "tiled/sheared" effect (multiple copies of the frame side-by-side).
On r0.6.0, the tiling is mostly gone, but the image is severely misaligned/squashed into a sub-region of the texture buffer.
Applying a manual UV Rect crop on the Unity side (e.g., W:0.5, H:0.5) partially recovers the image, proving the frame data is surviving the USB transfer but is being blitted into the wrong bounds/stride natively.
Steps to Reproduce
Import UVC4UnityAndroid (r0.6.0).
Set Unity Player Settings -> Graphics APIs to Vulkan.
Create a standard UI Canvas with a RawImage.
Attach UVCManager and UVCDrawer (dynamically or via Inspector).
Plug in a 1080p capture card on a Meta Quest 3.
Observe the squashed texture.
Switch Graphics API to OpenGLES3, rebuild, and observe the texture is now perfect.
Additional Context
I noticed that r0.5.0 introduced 16HB alignment support. Because 1080 is not divisible by 16 (it pads to 1088), I suspect the Vulkan render event / VkImage memory copy is misinterpreting the row stride or byte alignment for the decoded MJPEG/YUV frame, whereas the OpenGL texture upload handles it natively.
Because Meta Quest developers must use Vulkan for Passthrough and Depth API features, getting this experimental Vulkan path stabilized would be a massive win for the VR/MR community.
Is there any specific logging I can pull, or a specific format/resolution I should try forcing to bypass this Vulkan blit bug? Thank you again for your hard work on this repository!
Hello! First, thank you for this incredible plugin. It is the only reliable way to get UVC capture cards working in Unity on Android.
I am developing a Mixed Reality application for the Meta Quest 3. Because I need to use Meta's Depth API for MR occlusion, Vulkan is strictly required (Meta has deprecated OpenGLES3 for modern MR features).
However, I am encountering a severe texture rendering bug specifically when using the Vulkan Graphics API.
Environment
Device: Meta Quest 3 (Horizon OS / Android 12L)
Unity Version: 6000
Plugin Version: r0.6.0
Scripting Backend: IL2CPP (ARM64)
Graphics API: Vulkan (Bug occurs) / OpenGLES3 (Works perfectly)
UVC Hardware: Hagibis USB-C Capture Card
Requested Resolution: 1920x1080 (PreferH264 = false, defaults to MJPEG)
Expected Behavior (OpenGLES3)
When forcing Unity to use OpenGLES3, the video feed renders flawlessly. The 1920x1080 image fills the RawImage texture exactly as expected, confirming that the UVC negotiation, permissions, and C# UVCDrawer logic are perfectly correct.
Actual Behavior (Vulkan)
When switching Unity to Vulkan, the video feed is squashed, cropped, and pushed into the corner of the texture.
Earlier versions of the plugin produced a "tiled/sheared" effect (multiple copies of the frame side-by-side).
On r0.6.0, the tiling is mostly gone, but the image is severely misaligned/squashed into a sub-region of the texture buffer.
Applying a manual UV Rect crop on the Unity side (e.g., W:0.5, H:0.5) partially recovers the image, proving the frame data is surviving the USB transfer but is being blitted into the wrong bounds/stride natively.
Steps to Reproduce
Import UVC4UnityAndroid (r0.6.0).
Set Unity Player Settings -> Graphics APIs to Vulkan.
Create a standard UI Canvas with a RawImage.
Attach UVCManager and UVCDrawer (dynamically or via Inspector).
Plug in a 1080p capture card on a Meta Quest 3.
Observe the squashed texture.
Switch Graphics API to OpenGLES3, rebuild, and observe the texture is now perfect.
Additional Context
I noticed that r0.5.0 introduced 16HB alignment support. Because 1080 is not divisible by 16 (it pads to 1088), I suspect the Vulkan render event / VkImage memory copy is misinterpreting the row stride or byte alignment for the decoded MJPEG/YUV frame, whereas the OpenGL texture upload handles it natively.
Because Meta Quest developers must use Vulkan for Passthrough and Depth API features, getting this experimental Vulkan path stabilized would be a massive win for the VR/MR community.
Is there any specific logging I can pull, or a specific format/resolution I should try forcing to bypass this Vulkan blit bug? Thank you again for your hard work on this repository!