NDI feed often stagnates and doesn't reach OBS with low ndi_frame_rate

[codemann8]

At first, it seems the NDI feed works and will keep updating as long as you keep changing items, but after a minute or so of inactivity (no change) the NDI feed seems to stop. And periodically (1 frame every 5-10 minutes or so) it will update the frame but will still not stay current. This is observed on Windows 10. Opening up Broadcast View does re-establish the feed, but only for a few moments, then falls back into the same inactive phase.

Agent suggests it could be a too low frame rate that OBS recognizes it as a dead feed, but I have not been able to confirm.

[emosaru]

Investigation: NDI Feed Stagnation

Root cause: HiddenBroadcastWindow snapshot starvation when the main window is idle

Architecture summary

With EnableBackgroundNdi = true (the default), the visible BroadcastView's NdiSendContainer is set to NdiEnabled=false (dormant). Broadcasting is handled by HiddenBroadcastWindow, an off-screen window (Position=-32000,-32000, Opacity=0.01).

The hidden window has UseExternalCaptureDriver=true, so it does not start its own render-driven capture loop. Instead:

• It hooks into the main window's RequestAnimationFrame — every time the main window's compositor renders, a capture fires on the hidden window
• A slow-poll DispatcherTimer fires every 250ms to call TriggerCaptureAsync() (primarily for receiver-count polling, but also attempts captures)

Failure mode

When the user stops interacting (no item changes):

1. The main window's compositor stops requesting animation frames — RAF stops firing
2. The hidden window's compositor backing store is never refreshed
3. The 250ms timer keeps calling TriggerCaptureAsync(), which calls CreateCompositionVisualSnapshot() on the hidden window
4. CreateCompositionVisualSnapshot() returns null because the hidden window's visual hasn't been rasterized by the compositor since the last RAF tick
5. At NdiSendContainer.cs:453, the null snapshot is silently dropped:

   if (snapshot == null || _disposed) return;

6. No frames enter _pendingFrames. The send thread has nothing to send. OBS sees zero frame updates → feed appears dead.

Opening BroadcastView "fixes" it temporarily because BroadcastView is a visible window with NdiEnabled=true — its compositor backing store is actively rendered, so snapshots succeed. But once that window also idles, the same stagnation returns.

Relevant code locations

• NdiSendContainer.cs:450–454 — Snapshot capture, silent drop on null
• NdiSendContainer.cs:361–380 — Timer startup: external driver uses 250ms poll
• NdiSendContainer.cs:413–414 — Receiver-count check (only when hasReceivers)
• HiddenBroadcastWindow.axaml.cs:183–225 — RAF-driven capture loop
• BroadcastView.axaml.cs:67 — NdiEnabled gate based on EnableBackgroundNdi

Potential fixes

1. Force a render before snapshot — call InvalidateVisual() / explicit render trigger on the hidden window so the compositor backing store is fresh before CreateCompositionVisualSnapshot()
2. Send a heartbeat frame — periodically re-send the last known good frame when snapshots are stale, so OBS doesn't declare the feed dead
3. Periodic forced render — add a slow fallback timer that forces the hidden window to rasterize (e.g., InvalidateVisual() → await Task.Delay(16) → capture) to guarantee at least a few frames per second even when RAF isn't firing

---

The user's observation about "too low frame rate" is on the right track — the effective frame rate drops to near-zero when idle. The 250ms timer fires 4×/s but produces no frames because the snapshot is null, not because NDIlib rejects the frames.

---

Investigation performed by Hermes Agent (model: rdtand/Qwen3.6-27B-PrismaQuant-5.5bit-vllm).

[codemann8]

This seems to still occur on 3.0.3.2 .. I did some initial item marking and left it sit for about 10 minutes while I ate and when I clicked on another item, it didn't show in OBS. Opening up the Broadcast View window also didn't seem to trigger an update either.

[emosaru]

Very weird - I left the tracker idle for about 30 minutes and came back and clicked and NDI was still live and updating. Time to start investigating system/config-level issues...

[codemann8]

This could be related to two things:
I have set ndi_frame_rate to 3.0 which is likely not maintaining at least that rate with the 250ms builtin delay. Also, if I open NDI Tools - Studio Monitor, this too shows a massive delay sometimes in getting an update, so its not only an OBS issue. However, I have noticed some times when NDI Tools shows the feed updated and OBS does not, so OBS itself or the OBS-NDI plugin is definitely holding back in some capacity. But the fact I also see this behavior in Studio Manager tells me there is definitely some issue with EmoTracker not outputting that feed for a long duration.

[codemann8]

~~Potential fix: 6a46147 ~~

I'll have to run a larger test but prob might not get around to doing that for a couple days

Nvm, idk what is causing this to react so spotty, sometimes its good, sometimes its bad. Only thing that has changed is Emotracker v2 -> v3