CasparCG / help

File an issue here if you need help with CasparCG by the community-led support :+1:
https://casparcg.com
74 stars 8 forks source link

I implemented a basic NDI producer and consumer, and I'm looking for further guidance #18

Closed ianshade closed 5 years ago

ianshade commented 5 years ago

Hello awesome people! I decided to make a modern NDI producer and consumer. Probably my code isn't of high quality, definitely not pull-request-ready, but somebody may find it useful. If you decide to test it out, any feedback is welcome. (It requires NDI Redistributable to be installed in your system.)

Currently it supports only Windows and BGRA/BGRX pixel format. Here I'm looking for advice. Using YCbCr, especially for sources that don't use alpha, could bring better performance but NDI uses packed UYVY, while, if I'm correct, YCbCr in CasparCG is planar. Two solutions I have in mind are: using Swscale (I don't think it will be very efficient) or adding UYVY support to Caspar's core to allow the conversion to be performed on the gpu. How would you approach this problem?

Julusian commented 5 years ago

Thanks for doing this, I know this is a widely desired feature. I would suggest raising it as a PR anyway, as it will make it a lot easier for others to comment on your code and suggest ways to improve it.

This needs checking, but as far as I'm aware you will ask the NDI lib for video in a format, and it will always give it to you in that format, so you don't need to handle colour space conversions unless you think you can get it to perform better. I've never looked into how ycbcr colour spaces are handled in caspar, so can't currently comment on if it can be made to work as is. That feels like something that can come as a second PR though

ianshade commented 5 years ago

Okay, I'll make a PR after making some adjustments that already have been suggested by others or came to my mind. Yes, supporting only BGRA means that sources with other pixel formats will work with no problems but the NDI library has to perform the conversion (if needed, the library also deinterlaces and resamples audio). It probably is done in the fastest way a CPU can do it, but in my opinion it is still an unnecessary conversion and using 4:2:2 instead of 4:4:4:4 where possible would mean half as much data to move around. My non-scientific tests confirm that it changes a lot (almost double the performance) so I'll definitely look deeper into this 😃

Everton747 commented 5 years ago

Hello Ianshade, thank you for carrying out this work. Would it be possible to provide an already built version so that we can test?

ianshade commented 5 years ago

I published a release on my fork :) https://github.com/ianshade/server/releases/tag/v2.2.0-beta7-ndi-v1

mint-dewit commented 5 years ago

Closing this issue as a PR has been raised and further discussion can be had there: https://github.com/CasparCG/server/pull/1112