Bug: NDI Playback distorted

[jpc0]

Observed Behavior

It seems like the resolution being fed from NDI into the backend is incorrect. Could also the the pixel format but unlikely. I have attached pictures of the expected output vs what is actually being output. I see the same behaviour on both the decklink consumer output and output from screen consumer so it seems like the issues is before the consumer at the very least. The FFMPEG, IMAGE and COLOUR producers seem to work fine, this does seem restricted to the NDI producer.

I have made some code changes to try faultfinding:
I threw an exception at

server/src/modules/newtek/producer/newtek_ndi_producer.cpp

Line 199 in e4e9ed2

av_frame->format = AV_PIX_FMT_BGRA;

and it did not trigger so that confirms that it is in fact not taking that branch.

I also logged the width and height here:

server/src/modules/newtek/producer/newtek_ndi_producer.cpp

Line 204 in e4e9ed2

NDIlib_audio_frame_interleaved_32s_t audio_frame_32s;

and I can confirm the with and height is 1920x1080 which is the same width and height as the consumers & channel is running at. There are no errors reported from casparcg. A behaviour I did notice was that it takes quite a while (close to a minute) for the image to display and for the logging I placed for width and height to start printing. On windows there is never a delay.

I may try bumping to NDI V6 but that needs some code changes in casparcg, and seeing if that solves the problem.

Expected behaviour

NDI Playback works as expected, and is it does on windows.

Steps to reproduce

Playback NDI on linux

Environment

• Commit: HEAD
• Server version: v2.4.0
• Operating system: Ubuntu 22.04

[jpc0]

I can confirm switching to the libndi.so.6 library does not solve the problem. However on further testing turning off alpha on the sending device changes the level of stretching which makes me think it is an issue with stride/pixel format

[jpc0]

Some more information:

As mentioned in #1543 discussion it is also distorted on Windows builds. However when I tested it is working correctly on v2.4.0 release. Upon bisecting I found that commit e3289ec is the commit that broke the expected behaviour.

For those who got here by some sort of search:

A behaviour I did notice was that it takes quite a while (close to a minute) for the image to display and for the logging I placed for width and height to start printing.

That was caused by the firewall blocking ndi. Make sure your firewall rules allow communication between the server and the ndi source/destination.

[niklaspandersson]

I'll have a look at the (my) offending commit