TD Version 2023.12000, Windows 10
There are some issues with the NDI-Workflow currently present
NDI_Issues_Example.tox (3.4 KB)
NDI.Dat not working without initital cook.
The NDI Dat is not firing its callbacks without being cooked at least once. In the example.COMP see how NDI_Test2 Status par is updating, NDI_Test1 is not.
No clear way of checking if NDIIn.TOP has Signal
At least I cannot find a clear way of checking if the NDIIn.TOP currently has incoming signal or not.
The Info.CHOP will always show connection at 1 if the NDIIn.TOP was active at least once.
Potentialy uses wrong stream
Because of the non-existent way of fetching the status f the NDI-Top i cam up with the following soution using NDI.DAT selecting and deselecting the Inputs when the appear and disappear.
This can create issues when more then one stream is turned on or off in short time. (Not talking sub frame timings here.) resultin in the them getting mixed up and one of the NDIIn.TOPs displaying the wrong one.
High cook times on disabling
When disabling an NDIIn.TOP, we get a hefty lag, which interrestingly is not reflected in the frame time
We’re experiencing heavy frame drops too. Of course, we are enabling/disabling 18x 4K NDI streams at once… Not a show stopper but would be nice to improve performance here.
Thanks for the report. I’ve improved the behavior of the NDI DAT and the ‘connected’ channel. I’ve also reduce the amount of time that the file can stall when trying to tear down an inactive input. I’m not sure much more can be done for active streams, since we want to ensure that everything is torn down before moving onto doing another task.
Can you give more details about reproducing the issue with the mixed-up streams? Any steps to reproduce with your example file? I’ve spent some time trying but no luck yet.
Hi Malcolm,
thanks for looking in to it.
Regarding the repoducing: Relatively quikcly changing the On/Off state of the testerCOMP should result in this behaviour.
After some testing I realised that it seems to not be the intendet way of handling NDI-Streams though. We tested two NDI-Encoders with the following way of handling it:
- Kiloview sends a predefined image instead of the stream. The stream itself stays up and continues to send images.
- Magwell just stops sending ata alltogether. The stream is still active and connected, but the FPS go to 0. (which I kinda like most atm.) Maybe it would be nice to implement this in TD to, instead of killing the stream just stopping the dataflow.
