Yes that’s correct. What I’m not sure is whether the underlying transport is different to NDI Screen capture for Spout2NDI as the screen capture feed has a delay of about 2 secs. Given NDI is used for gaming there should be latencies less then 50ms.
I do not find high latency for NDI screen capture but rather hesitations unless set to 60fps. The region of interest function suggests that the whole screen is captured, possibly by DXGI screen duplication which is very efficient. The reason for the hesitation is likely to be something else.
Spout to NDI takes the Spout sender’s texture as input, downloads the pixels from GPU to CPU and sends that buffer to NDI.
The overhead for GPU>CPU download is reduced with the “Texture readback buffering” setting and the NDI sending is optimized by the “YUV format sending” setting. The underlying NDI send function operates as provided for by the NDI SDK.
Ok, got this setup. While it’s better it’s still visibly behind in OBS. However the interesting thing is the NDI monitor on the OBS end is almost identical to the Synesthesia source which would eliminate the network (Wifi at the moment) and also confirm the performance of Spout2NDI. I wonder whether I can further fine tune the OBS NDI plugin/OBS setup which may be a question for another forum. At the moment it’s still not usable.
However back to Spout2NDI do you think shrinking the region of interest could improve performance?
Reducing the region of interest in the NDI capture application would make a difference by reducing the size of the NDI image. The same would apply to the Spout source for Spout to NDI. My experience is that anything above 1920x1080 has poor performance.
I am not sure how you would fine tune the OBS NDI plugin unless there are user settings you can adjust.
If you can isolate the latency of 2 seconds to NDI screen capture, it’s worth asking on the NDI forum.