PDA

View Full Version : How to handle NDI stream delays?



ddv2005
01-03-2018, 09:18 PM
Hello,
I have NDI receiver application and in normal case all video/audio frames coming at desired time. But how to handle situations when some network errors occurs that causes NDI stream delays? Does NDI SDK will drop late video and audio frames or application have to do it? How properly handle situation when SDK send several video frames with delay less than frame rate (example 2 frames in 5ms on 60FPS)? Does application need to have some jitter buffer or SDK handle it?

Best Regards,
Dmitry

livepad
01-04-2018, 10:36 AM
Hello,
I have NDI receiver application and in normal case all video/audio frames coming at desired time. But how to handle situations when some network errors occurs that causes NDI stream delays? Does NDI SDK will drop late video and audio frames or application have to do it? How properly handle situation when SDK send several video frames with delay less than frame rate (example 2 frames in 5ms on 60FPS)? Does application need to have some jitter buffer or SDK handle it?

Best Regards,
Dmitry

All incoming data is timestamped, which communicates the actual program time, vs arrival time

Not certain about it but I believe in extreme situations the receiver may disconnect (then perhaps reconnect ?) if the network conditions are causing lost data.

ddv2005
01-04-2018, 11:04 AM
Regular network streams (like HTTP MPEGTS) required to have some jitter buffer and it is application responsibility to drop late frames in case of delays and etc. My question is it also required for NDI or NDI SDK care about it?
In my situation for some reason TCP traffic stall on about 300ms and after restoration SDK send several frames in less than 5ms.

livepad
01-06-2018, 05:36 AM
Regular network streams (like HTTP MPEGTS) required to have some jitter buffer and it is application responsibility to drop late frames in case of delays and etc. My question is it also required for NDI or NDI SDK care about it?
In my situation for some reason TCP traffic stall on about 300ms and after restoration SDK send several frames in less than 5ms.

It sounds like the NDI / TCP combination is doing that. All the frames are arriving, but not in a linear motion. This is fairly typical of TCP traffic on am erratic connection or where one end or the other is over loaded.

This is where the NDI Timetamps will help you. You can smooth out the non-linearity of arrival with your own smoothing (de-jitter) buffer.

The Sienna NDI Monitor for Mac has 3 different modes which work like that. The Low Latency mode just delivers NDI data as it arrives with no smoothing. Turning off Low Latency adds a scheduling engine with a small latency but still essentially uses the arrival times to schedule, then finally the 'use Source Timestamps' (actually time*code*) method respects the 'timecode' settings in the NDI Packets to define the layout scheduling, assuming that the NDI sender accurately set those.

Note that in NDI 3.0 NewTek has added an extra layer of (real) timestamps (rather than timecode) where the sending NDI library is timestamping NDI packets as they are SENT. In this case the NDI arrivals should have accurate send times regardless of network conditions and this is the best way to 'straighten out' an NDI stream.

However, older NDI libraries do not send this information so its not a universal solution.

Good Luck !

ddv2005
01-06-2018, 10:19 AM
Thanks for your reply. I will try to do the same.