VideoStreamTrack fails to start streaming in 3.0.0-pre.8 (worked fully stable on 3.0.0-pre.4, partial crash on pre.6)

[merttalhayener]

Package version

3.0.0-pre.8

Environment

* OS:Android (HTC - Oculus VR Devices)
* Unity version:6000.0.49f1

Steps To Reproduce

1.	Create a Unity project (tested with Unity 6000.0.49f1).
2.	Install com.unity.webrtc package with different versions: pre.4, pre.6, and pre.8.
3.	Set up a simple video streaming scenario using VideoStreamTrack to stream a RenderTexture from VR device (Oculus/HTC Vive Focus, OpenXR, Vulkan backend).
4.	Start WebRTC signaling and establish peer connection successfully.
5.	Once the video stream starts, observe behavior on each version.

Current Behavior

•	✅ In 3.0.0-pre.4: Streaming works fully stable, video frames are continuously streamed, no crashes or rendering issues observed.
•	⚠ In 3.0.0-pre.6: Streaming starts, first frames are correctly sent, but the application crashes after 1–5 seconds randomly. Sometimes crashes after first frame, sometimes after a few seconds.
•	❌ In 3.0.0-pre.8: Streaming never starts, VideoStreamTrack creation fails immediately or rendering crashes instantly. In some cases, encoder context is not fully initialized before first frame delivery.

All versions successfully complete peer connection, signaling, and ICE negotiation. The problem is purely at the rendering/encoder binding level after the video streaming starts.

On Unity Editor all versions successfully complete peer connection, signaling, and ICE also Video Streaming. It seems like the problem comes with the version update only affects Android devices.

Expected Behavior

•	VideoStreamTrack should continue streaming frames consistently after the connection is established, without random crashes.
•	Encoder binding should behave identically across all 3.x versions.
•	New versions (pre.6 and later) should maintain compatibility with rendering stability that was working properly in pre.4.

Anything else?

Issue fully reproduces even when using Unity Render Streaming package (which internally uses com.unity.webrtc as its core dependency).
• Same behavior is observed on Render Streaming package:
• When Render Streaming uses WebRTC 3.0.0-pre.8 or pre.6, identical crashes occur (either immediately or a few seconds after starting the video stream).
• After downgrading Render Streaming’s internal WebRTC package to 3.0.0-pre.4, streaming works fully stable.
• This strongly suggests the root cause is inside the WebRTC package itself, and affects any downstream solution that builds on top of it.

[himanchalsharmaa]

@merttalhayener Is your graphics API set to Vulkan/Auto for Android?

[merttalhayener]

@merttalhayener Is your graphics API set to Vulkan/Auto for Android?

Yes, in my project settings, “Auto Graphics API” is disabled, and Vulkan is explicitly selected as the Graphics API.

[himanchalsharmaa]

@merttalhayener Is your graphics API set to Vulkan/Auto for Android?

Yes, in my project settings, “Auto Graphics API” is disabled, and Vulkan is explicitly selected as the Graphics API.

Then this is your culprit most probably. There's some issues with Vulkan Initialisation on Quest headsets.
Try OpenGL ES3(Multipass with MSAA or Singlepass without MSAA) and see if it works.

[merttalhayener]

@merttalhayener Is your graphics API set to Vulkan/Auto for Android?

Yes, in my project settings, “Auto Graphics API” is disabled, and Vulkan is explicitly selected as the Graphics API.

Then this is your culprit most probably. There's some issues with Vulkan Initialisation on Quest headsets. Try OpenGL ES3(Multipass with MSAA or Singlepass without MSAA) and see if it works.

Actually, this is exactly what I was referring to when I initially opened the issue. Ideally, I shouldn’t need to make any changes on my side. Everything works flawlessly with Vulkan in version 3.0.0-pre.4, but just two versions later, the application sends a single frame and crashes—and in the latest version, no frame is transmitted at all.

I’ve tested this behavior on both Meta Quest and HTC Vive headsets, and the result is exactly the same on both platforms. So this is not limited to Quest-specific behavior.

This is something the development team should seriously consider, as many VR applications rely on Vulkan as their primary graphics API.

[himanchalsharmaa]

@merttalhayener Is your graphics API set to Vulkan/Auto for Android?

Yes, in my project settings, “Auto Graphics API” is disabled, and Vulkan is explicitly selected as the Graphics API.

Then this is your culprit most probably. There's some issues with Vulkan Initialisation on Quest headsets. Try OpenGL ES3(Multipass with MSAA or Singlepass without MSAA) and see if it works.

Actually, this is exactly what I was referring to when I initially opened the issue. Ideally, I shouldn’t need to make any changes on my side. Everything works flawlessly with Vulkan in version 3.0.0-pre.4, but just two versions later, the application sends a single frame and crashes—and in the latest version, no frame is transmitted at all.

I’ve tested this behavior on both Meta Quest and HTC Vive headsets, and the result is exactly the same on both platforms. So this is not limited to Quest-specific behavior.

This is something the development team should seriously consider, as many VR applications rely on Vulkan as their primary graphics API.

Have you tried the No Vulkan Hook project?
https://github.com/UCL-VR/unity-webrtc-no-vulkan-hook

[himanchalsharmaa]

Package version

3.0.0-pre.8

Environment

• OS:Android (HTC - Oculus VR Devices)
• Unity version:6000.0.49f1

Steps To Reproduce

1.	Create a Unity project (tested with Unity 6000.0.49f1).
2.	Install com.unity.webrtc package with different versions: pre.4, pre.6, and pre.8.
3.	Set up a simple video streaming scenario using VideoStreamTrack to stream a RenderTexture from VR device (Oculus/HTC Vive Focus, OpenXR, Vulkan backend).
4.	Start WebRTC signaling and establish peer connection successfully.
5.	Once the video stream starts, observe behavior on each version.

Current Behavior

•	✅ In 3.0.0-pre.4: Streaming works fully stable, video frames are continuously streamed, no crashes or rendering issues observed.
•	⚠ In 3.0.0-pre.6: Streaming starts, first frames are correctly sent, but the application crashes after 1–5 seconds randomly. Sometimes crashes after first frame, sometimes after a few seconds.
•	❌ In 3.0.0-pre.8: Streaming never starts, VideoStreamTrack creation fails immediately or rendering crashes instantly. In some cases, encoder context is not fully initialized before first frame delivery.

All versions successfully complete peer connection, signaling, and ICE negotiation. The problem is purely at the rendering/encoder binding level after the video streaming starts.

On Unity Editor all versions successfully complete peer connection, signaling, and ICE also Video Streaming. It seems like the problem comes with the version update only affects Android devices.

Expected Behavior

•	VideoStreamTrack should continue streaming frames consistently after the connection is established, without random crashes.
•	Encoder binding should behave identically across all 3.x versions.
•	New versions (pre.6 and later) should maintain compatibility with rendering stability that was working properly in pre.4.

Anything else?

Issue fully reproduces even when using Unity Render Streaming package (which internally uses com.unity.webrtc as its core dependency). • Same behavior is observed on Render Streaming package: • When Render Streaming uses WebRTC 3.0.0-pre.8 or pre.6, identical crashes occur (either immediately or a few seconds after starting the video stream). • After downgrading Render Streaming’s internal WebRTC package to 3.0.0-pre.4, streaming works fully stable. • This strongly suggests the root cause is inside the WebRTC package itself, and affects any downstream solution that builds on top of it.

@merttalhayener There's a workaround to this: if you rebuild the plugin with EXPORT_HANDLE = false in VulkanTexture2D::Init function, it works just fine. Here's the Android plugin I built and tested today: https://github.com/himanchalsharmaa/UnityWebrtcQuestVulkanFix/tree/master/Runtime/Plugins/Android
@karasusan It seems that with EXPORT_HANDLE = true it fails to Allocate Memory in vkAllocateMemory(VulkanUtility.cpp), most probably due to External Memory Handle Type being set as VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_WIN32_BIT_KHR in VulkanUtility.cpp, even for Android.

[merttalhayener]

Package version

3.0.0-pre.8

Environment

• OS:Android (HTC - Oculus VR Devices)
• Unity version:6000.0.49f1

Steps To Reproduce

1.	Create a Unity project (tested with Unity 6000.0.49f1).
2.	Install com.unity.webrtc package with different versions: pre.4, pre.6, and pre.8.
3.	Set up a simple video streaming scenario using VideoStreamTrack to stream a RenderTexture from VR device (Oculus/HTC Vive Focus, OpenXR, Vulkan backend).
4.	Start WebRTC signaling and establish peer connection successfully.
5.	Once the video stream starts, observe behavior on each version.

Current Behavior

•	✅ In 3.0.0-pre.4: Streaming works fully stable, video frames are continuously streamed, no crashes or rendering issues observed.
•	⚠ In 3.0.0-pre.6: Streaming starts, first frames are correctly sent, but the application crashes after 1–5 seconds randomly. Sometimes crashes after first frame, sometimes after a few seconds.
•	❌ In 3.0.0-pre.8: Streaming never starts, VideoStreamTrack creation fails immediately or rendering crashes instantly. In some cases, encoder context is not fully initialized before first frame delivery.

All versions successfully complete peer connection, signaling, and ICE negotiation. The problem is purely at the rendering/encoder binding level after the video streaming starts.
On Unity Editor all versions successfully complete peer connection, signaling, and ICE also Video Streaming. It seems like the problem comes with the version update only affects Android devices.

Expected Behavior

•	VideoStreamTrack should continue streaming frames consistently after the connection is established, without random crashes.
•	Encoder binding should behave identically across all 3.x versions.
•	New versions (pre.6 and later) should maintain compatibility with rendering stability that was working properly in pre.4.

Anything else?

Issue fully reproduces even when using Unity Render Streaming package (which internally uses com.unity.webrtc as its core dependency). • Same behavior is observed on Render Streaming package: • When Render Streaming uses WebRTC 3.0.0-pre.8 or pre.6, identical crashes occur (either immediately or a few seconds after starting the video stream). • After downgrading Render Streaming’s internal WebRTC package to 3.0.0-pre.4, streaming works fully stable. • This strongly suggests the root cause is inside the WebRTC package itself, and affects any downstream solution that builds on top of it.

@merttalhayener There's a workaround to this: if you rebuild the plugin with EXPORT_HANDLE = false in VulkanTexture2D::Init function, it works just fine. Here's the Android plugin I built and tested today: https://github.com/himanchalsharmaa/UnityWebrtcQuestVulkanFix/tree/master/Runtime/Plugins/Android @karasusan It seems that with EXPORT_HANDLE = true it fails to Allocate Memory in vkAllocateMemory(VulkanUtility.cpp), most probably due to External Memory Handle Type being set as VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_WIN32_BIT_KHR in VulkanUtility.cpp, even for Android.

Yes, when I tested with the Android plugin you sent, the video was successfully transmitted to the other side without any issues. Thank you for getting to the root of the problem and reporting it to the developers—hopefully, they will release an update regarding this soon.

[AlexRadacki]

We've created an issue about this, and had it verified:

https://issuetracker.unity3d.com/issues/android-vulkan-the-video-is-not-streamed-when-it-is-added-with-rtcrtpsender-dot-addtrack-method

Please vote it up, to push the importance - thanks!

[himanchalsharmaa]

We've created an issue about this, and had it verified:

https://issuetracker.unity3d.com/issues/android-vulkan-the-video-is-not-streamed-when-it-is-added-with-rtcrtpsender-dot-addtrack-method

Please vote it up, to push the importance - thanks!

Voted. Although, you're better off using the custom link. I had built that because of another optimization bug(https://issuetracker.unity3d.com/issues/quest-gles3-transparent-materials-disappear-due-to-fullscreenrenderpass-on-quest-when-multiview-slash-spi-is-used-with-msaa-on-opengles3) that they've still not fixed. And that one is far major and current .
This project is most probably dead : #1084

[FireDragonGameStudio]

We've created an issue about this, and had it verified:
https://issuetracker.unity3d.com/issues/android-vulkan-the-video-is-not-streamed-when-it-is-added-with-rtcrtpsender-dot-addtrack-method
Please vote it up, to push the importance - thanks!

Voted. Although, you're better off using the custom link. I had built that because of another optimization bug(https://issuetracker.unity3d.com/issues/quest-gles3-transparent-materials-disappear-due-to-fullscreenrenderpass-on-quest-when-multiview-slash-spi-is-used-with-msaa-on-opengles3) that they've still not fixed. And that one is far major and current . This project is most probably dead : #1084

Do you know of a maintained fork ob the webrtc package? I'm using it for pretty everything RTC related SimpleWebRTC and even expanded it to work with web clients SimpleWebRTC-Web. Currently working on a WebRTC based "cross-platform spectator app" and already ran into multiple issues. Oo

[himanchalsharmaa]

We've created an issue about this, and had it verified:
https://issuetracker.unity3d.com/issues/android-vulkan-the-video-is-not-streamed-when-it-is-added-with-rtcrtpsender-dot-addtrack-method
Please vote it up, to push the importance - thanks!

Voted. Although, you're better off using the custom link. I had built that because of another optimization bug(https://issuetracker.unity3d.com/issues/quest-gles3-transparent-materials-disappear-due-to-fullscreenrenderpass-on-quest-when-multiview-slash-spi-is-used-with-msaa-on-opengles3) that they've still not fixed. And that one is far major and current . This project is most probably dead : #1084

Do you know of a maintained fork ob the webrtc package? I'm using it for pretty everything RTC related SimpleWebRTC and even expanded it to work with web clients SimpleWebRTC-Web. Currently working on a WebRTC based "cross-platform spectator app" and already ran into multiple issues. Oo

I don't know of anything being actively maintained. Your best bet is to build it yourself(the package has build scripts). For your issue(#1087), it doesn't look like the plugin needs rebuilding .
Instead of going via package manager, just put the runtime folder(https://github.com/Unity-Technologies/com.unity.webrtc/tree/5f873f2ac17f3514ffe8a8514e94bff5e93e3982/Runtime) in your Assets and modify the resolution in Webrtc.cs as you pointed out.
Do watch out for encoder-decoder errors though, there's a reason why that bound is there.

[FireDragonGameStudio]

We've created an issue about this, and had it verified:
https://issuetracker.unity3d.com/issues/android-vulkan-the-video-is-not-streamed-when-it-is-added-with-rtcrtpsender-dot-addtrack-method
Please vote it up, to push the importance - thanks!

Voted. Although, you're better off using the custom link. I had built that because of another optimization bug(https://issuetracker.unity3d.com/issues/quest-gles3-transparent-materials-disappear-due-to-fullscreenrenderpass-on-quest-when-multiview-slash-spi-is-used-with-msaa-on-opengles3) that they've still not fixed. And that one is far major and current . This project is most probably dead : #1084

Do you know of a maintained fork ob the webrtc package? I'm using it for pretty everything RTC related SimpleWebRTC and even expanded it to work with web clients SimpleWebRTC-Web. Currently working on a WebRTC based "cross-platform spectator app" and already ran into multiple issues. Oo

I don't know of anything being actively maintained. Your best bet is to build it yourself(the package has build scripts). For your issue(#1087), it doesn't look like the plugin needs rebuilding . Instead of going via package manager, just put the runtime folder(https://github.com/Unity-Technologies/com.unity.webrtc/tree/5f873f2ac17f3514ffe8a8514e94bff5e93e3982/Runtime) in your Assets and modify the resolution in Webrtc.cs as you pointed out. Do watch out for encoder-decoder errors though, there's a reason why that bound is there.

K, thx for the update. Let's see if I can do smth to get stuff working ^^