NDIlib_framesync_capture_video() v5.x dropping frames ?

M

MikOfClassX

New member
Hello all,

After updating NDI runtimes (win10 x64) from v4.5.3.x to 5.0.1.x, capturing using NDIlib_framesync_capture_video() is no longer frame-synched as it was before.
Captured video is dropping frames. NDI sender and receiver are both set to 1080i50.

Is anyone experiencing the same issue ?

Mik
 
I found that more recent runtimes don't *drop* frames but deliver them very unevenly. (I'm not actually using the framesync in production, but doing so didn't change anything.)

I wrote a small app to capture frames and look at both the time codes on the frames and the gaps between receiving them. The results are really interesting. In both runtimes, the time code tick differences are steady at ~333K per frame. In the 4.6.2.0 runtime, the observed tick differences do vary, but they're almost always in the range of 200K-400K. In the 5.0.9.0 runtime, the observed tick differences vary much more significantly - usually alternating between < 100K and > 500K. That entirely explains why the displayed image isn't smooth - there can be large gaps between frames being reported.

I *suspect* that's the same issue you're running into, but obviously there could be more to it. Personally I'm just sticking with 4.6.2.0 for the moment.
 
I'm a new NDI user, giving a try to NDIlib_framesync_capture_video with SDK v5.3.3.

Did you both stay with NDI 4.5 / 4.6 ? or did you see improvements since you posted ?
 
I'm currently still on 4.6.2.0. I have tried more recent NDI SDKs and still observed the same behavior - it's possible that I haven't tried the *absolutely most recent* one though.
 
jonskeet said:
I found that more recent runtimes don't *drop* frames but deliver them very unevenly.
Click to expand...
Would this observation also apply to simply looking at an NDI stream in software, or only when capturing one to disk? Are you saying that 4.6.2 is better at smoothly displaying NDI streams in software than all 5.x versions?
 
This has nothing to do with disks. (While my test app does write to disk, it only does so after capturing everything in memory.)

Yes, 4.6.2 is better at smoothly displaying NDI streams, at least in the context I'm using it in. (Low latency, and using the .NET SDK - I seem to remember observing the same thing with the NDI monitor in low latency mode as well. It's been a while since I've looked into it in detail though.)
 
jonskeet said:
Yes, 4.6.2 is better at smoothly displaying NDI streams, at least in the context I'm using it in. (Low latency, and using the .NET SDK
Click to expand...
I wonder why NDI 5's SDK is worse than NDI 4.6's SDK. I mean, is this defect cured in the Advanced SDK? Or, is it just plain worse all around?
 
videooperator said:
I wonder why NDI 5's SDK is worse than NDI 4.6's SDK. I mean, is this defect cured in the Advanced SDK? Or, is it just plain worse all around?
Click to expand...
Given that the NDI Studio Monitor still (v5.5.3.0) has the same issue, where you have to basically choose between "smooth with significant latency" or "low latency but jerky" I would assume it's just plain worse.

It's possible that this is something about the camera/SDK pairing, of course - other cameras may work better with the newer SDKs. (I mostly use PTZ Optics PT30x-NDI-G2 cameras, and the "NDI Firmware" version is 4.6.3...)
 
If you all recall, something new with NDI 5 was the addition of the RUDP transmission protocol. Perhaps it is not working well for your scenarios. You can disable it with NDI Access Manager.
 
brianbrice said:
If you all recall, something new with NDI 5 was the addition of the RUDP transmission protocol. Perhaps it is not working well for your scenarios. You can disable it with NDI Access Manager.
Click to expand...
Thanks for the suggestion - I've tried this just now, and it didn't make any difference to the NDI Monitor at least - still jerky with low latency :(
If I ever end up with a genuine NDI 5 source, I'll give that a try... it would be very unusual for this regression to go generally unnoticed. For the moment, I'll stick with the 4.6.2 SDK for my use case of church broadcasting.

(I'll happily keep trying newer versions as they come out, of course.)
 
jonskeet said:
Thanks for the suggestion - I've tried this just now, and it didn't make any difference to the NDI Monitor at least - still jerky with low latency :(
If I ever end up with a genuine NDI 5 source, I'll give that a try... it would be very unusual for this regression to go generally unnoticed. For the moment, I'll stick with the 4.6.2 SDK for my use case of church broadcasting.

(I'll happily keep trying newer versions as they come out, of course.)
Click to expand...
I noticed this thread. Does this information help? Yes or no?

 
brianbrice said:
If you all recall, something new with NDI 5 was the addition of the RUDP transmission protocol. Perhaps it is not working well for your scenarios. You can disable it with NDI Access Manager.
Click to expand...
Hi Brian Brice,

I really seriously hesitate to write this, because my experiments are not conclusive. But, the easiest example I can provide to substantiate what is being discussed here is this: I am unable to stream NDI out of any software on an M1 Pro MBP to any NDI receiver on the same MacBook without it dropping frames. So, to be clear: no network connected. This is all 127.0.0.1 (loopback, I guess this is called?). I have tried Final Cut Pro using the NDI output utility and I have also tried Sienna NDI Signal Generator. In both instances, the exact resolution and frame rate was 1080p60. If NDI cannot be free from frame drops on a single system, without a network, then what hope do any of us have once it's networked? Gotta be honest, after thoroughly evaluating this on macOS, I am pretty disappointed. Next step for me is to re-evaluate NDI on Windows 11 and also re-evaluate using an FPGA encoder and decoder.

Preliminary conclusion: NDI on macOS only reliably delivers and/or displays 98% of the frames, and routinely loses about 2% of frames.

I'd be delighted to know why.

P.S. - The three methodologies used to determine that frames are being dropped in NDI Monitor are simple: (1) HDMI output from Mac to HDMI video recorder. Watch playback frame-by-frame. (2) Filming the MacBook display with an iPhone. Watch playback frame-by-frame. (3) Doing a screen recording using the Mac built-in screen recording app. Watch playback frame-by-frame.
 
Last edited:
You must log in or register to reply here.
Back
Top