Forum

VL.IO.NDI

@Elias I actually do have this in a private repo here because the DLL used in the VL implementation is based on is a modified example from the SDK. However, the license for the SDK allows only redistribution of headers and redistributable files, therefore I was hesitant at that time. (i might also just write them to ask if it was ok to opensource the example…).

I’ll split VL and the DLL into two projects, make the VL public and give you access to the DLL as well. It seems the DLL needs an update anyway as there were some minor changes in the naming within NDI. it just might take a day or so…

sorry for the inconvenience…

1 Like

@motzi @tonfilm @elias thanks for having a look at this, appreciate your time!

@tobyk: could you try this and tell me if it works for you? it does not contain a sender node yet but is updated to the latest NDI version (4.5) which gives improved perfomance.

VL.IO.NDI_200408.7z (1.4 MB)

3 Likes

@motzi thanks for your quick work! The receiver is working great.

image

a super naive sender is just these few nodes:

image

i just was surprised that it just worked without any tinkering. of course one does want to tinker a bit to make it async, i guess

4 Likes

Yeah, the Sender base-nodes are still there from the last release. Since i did restructure the thing internally quite a bit I did not bother to create a Sender as i figured that a receiver would be more important.

However, a release on Github is imminent since the NewTek people responded positively regarding opensource publishing

5 Likes

I spent some more time on this and now released everything on Github:

Furthermore here is a ready-to-use version of the whole thing with the latest changes
VL.IO.NDI_200413.7z (1.8 MB)

For future releases there will be a nuget pipeline that I still have to set up.

The latest changes feature some performance improvements for the Receiver and experimental Sender nodes. Caution with those - they are not synced to any Renderer and the NDI videostreams are prone to jitter.

  • Sender: Blocking version that will throttle the patch according to the set frame rate
  • ReactiveSender: This one is clocked by a BusyWaitTimer internally and therefore processes frame sending on a different thread. Beware: Closing the patch while still sending video will crash VVVV (I did not figure out how to safely check if frames/sender are already disposed in the other thread).

The whole Sending topic will need more research (and probably some help by the devs - e.g. is it possibly to get a sync info from the Renderer?). Also i just noticed there is an async version of the NDI send function.

Anyone interested in joining in the development is welcome as I don’t always have time for this. There is still a lot to be done (proper sending, audio and metadata support, timecode, …).

Enjoy!

6 Likes

now this is also available as a nuget:

5 Likes

This might be some kind of dumb question, but how the hell do I get this to run in vvvv? Is this intended to be used in vvvv, anyway? Or is this stuff for vl only?? And if so: what to use for streaming DX11-Content to Resolume on a Multi-GPU-System, then? I want to learn VL anytime soon, but for now, I just need to share my renderer with Reso. Spout doesn´t work (seems like this is due to my eGPU-Setup) and I would like to use NDI for an upcoming project. tl;dr -> Heeelp!

hey @cznickesz
the latest version (nuget) was built for VL only - there is no wrapper included for a vvvv beta node. you might want to have a look at the version from october 2018 (see above) for that. not sure if the latest VL.IO.NDI would work for current beta as the dependencies might only work for the latest VL backend (which will hopefully be available in beta 40 - hard to say when this will happen).

however, streaming from a DX11 renderer to NDI (using the old version) is not really well tested yet and I would not expect super fluid framerates. since you are on the same machine with resolume i’d rather look into getting spout or some other form of texture sharing to work. i don’t have much experience with that though…

this has worked for me in the past: https://vvvv.org/contribution/spout-dx11

Hey Motzi, thx for your reply. I´ll keep trying to get spout up and running then for the time being. And this does show once again that I do need to finally get some vl into my brain/workflow. @sunep already tried that but having some general spout-problems due to my setup (Intel vs discrete GPU vs eGPU). I´ll keep trying, though!

Hi all! Thanks for this great contribution. It would be super useful to have this working, it can change the whole usability of Gamma with Stride. According to github repo there is no change for 8 months. Is there any essential issue which is not possible to overcome? Like also discussed in topic here Crash when adding the VL.IO.NDI dependency

hey @karafiat,

due to VL internal changes this packages needs an update to work on versions > 2020.2.x
i did not have time to look into this until now, however it is still alive and waits to be tackled. hopefully i can invest the necessary effort during the holidays. if anyone else wants to contribute the changes - this would be very welcome, sources are on github!

stay tuned!

2 Likes

Thanks @motzi for your effort! Maybe it makes sence also to wait for official release of 2020.3. – I don´t know. I can´t help with code itself, it’s over my scope. But I can help with testing for sure.

VL.IO.NDI was just updated to version 0.2.2-alpha.

  • works now in gamma 2020.3 (pulling in the hotfix by @bjoern - thanks!)
  • native NDI dll was updated to version 4.5.3
  • updated VL.Audio reference to version 0.2.18

still todo:

  • providing output as a stride texture
4 Likes

@motzi great!
Connection seems stable. Regarding the Sender, is there way to go directly from Stride texture to
SenderTexture (it needs SharpDX.Direct3D11.Texture2d) or it is so far necessary to use long way from GPU to CPU and back via TextureToImage -> FromImage -> Sender. Which almost kills CPU on higher resolution.
Capture

it should be quite fast when you have enough frames of delay. how is your delay setting of the TextureToImage in that screenshot?

but anyway, that’s a really huge resolution, depending on your machine, it might simply be too much data to process.

I use default 3 frames, on this resolution, increasing this number doesn’t really affects the result.

Meanwhile current Spout in latest 2020.3 preview is so far fluid even on this huge resolution. (I´m using I7-7700, RTX 2060)

1 Like

yes, spout is on GPU, NDI will be over CPU and is way slower, but can be sent over the network while Spout only works on the same machine on the same GPU.