We have been troubleshooting an odd issue for a while and were curious what the community thinks. On a dedicated NDI Network we would like the ability to use up to 7 HX-NDI streams. At times one Standard NDI stream could be utilized as well. The Cameras we are using are all Marshall CV630-NDI PTZ UHD Camera’s all flashed with the latest firmware. These cameras are connected to an AV Line Netgear M4250-26G4XF-POE+ Switch connected to our Streaming PC via a 1Gig link. Max traffic that we usually see on this link is about 190Mbps when all of these cameras are going. AMD Ryzen Threadripper 2950X, 32GB RAM, RTX 2060. We can manage 6 NDI connections decently if the Cameras are set to 1080p30. 5 of the connections are the CV630’s using NDIHX Streams and 1 HDMI capture using NDI FULL stream. We experience these frame drops regardless of application as well. OBS, VMIX, and Wirecast all present these frame drops in the same manner. The oddest thing is the frame drops are only present after it passes through the Application Preview Window. The video sent directly from the Camera and/or NDI FULL stream is unaffected until it reaches this point. If this didn’t also affect the recording and the stream this would be a non-issue. But unless we are missing something frame drops are injected on our stream after we exceed 5 streams or so. We’ve performed basic network tests and nothing obvious is jumping out at us. We were just curious if anyone else has ran into a similar issue in their NDI setups and if they could help point us in the right direction. Thanks, Curt Cooper | |||||||
Dropped Frames in OBS Preview Window and Stream/Recording Output
- Thread starter coritgmun
- Start date
tlv1studios
New member
This exactly! I'm surprised I have not seen more posts about it.
We are experiencing the same exact issue with our 2x Canon CR-N300 NDI-HX cameras, also on a dedicated POE switch. Just as you write Curt, the direct video feed does not display dropped frames, but as soon as it goes through OBS or Wirecast's Live/Preview window (we're using an M1 Max MacBook Pro, so it's interesting to hear the same issue appears on VMix on Windows) the dropped frames are quite visible and are also in the recorded file. The issue is so prevalent that it is nearly impossible to use the NDI feeds through these apps. Surprisingly, when recording the ISO feeds in Wirecast, there are no dropped frames. But the Live/Preview window and recording does display these dropped frames.
Important to note! The dropped frames are not due to the apps' ability to cope with the feeds. They display no dropped frames due to app/system/memory issues. The dropped frames appear to be in the decode/encode process, and therefore appear to be a driver issue.
We have been troubleshooting this for a couple months with no success. We're resorting to going via HDMI until the issue is fixed.
I'd be happy to supply recordings (Live and ISO feeds to show the discrepancies between them) or other technical details to try and help NewTek narrow down the issue!
Help!
We are experiencing the same exact issue with our 2x Canon CR-N300 NDI-HX cameras, also on a dedicated POE switch. Just as you write Curt, the direct video feed does not display dropped frames, but as soon as it goes through OBS or Wirecast's Live/Preview window (we're using an M1 Max MacBook Pro, so it's interesting to hear the same issue appears on VMix on Windows) the dropped frames are quite visible and are also in the recorded file. The issue is so prevalent that it is nearly impossible to use the NDI feeds through these apps. Surprisingly, when recording the ISO feeds in Wirecast, there are no dropped frames. But the Live/Preview window and recording does display these dropped frames.
Important to note! The dropped frames are not due to the apps' ability to cope with the feeds. They display no dropped frames due to app/system/memory issues. The dropped frames appear to be in the decode/encode process, and therefore appear to be a driver issue.
We have been troubleshooting this for a couple months with no success. We're resorting to going via HDMI until the issue is fixed.
I'd be happy to supply recordings (Live and ISO feeds to show the discrepancies between them) or other technical details to try and help NewTek narrow down the issue!
Help!
SBowie
'the write stuff'
A couple of comments:
First, while I understand the temptation to reach that conclusion, I'm not at 100% certain that this really is "the same exact issue". It's entirely possible that it is, or perhaps the seeming similarities are just that. The profusion of gear and software mentioned in two reports don't make it easy to determine whether there is a common factor, or - if there is - whether different implementations by different developers may have made identical missteps, or whether this represents some unforeseen problem with the NDI SDK (the developers may not be using the same one, btw). I could go on, but perhaps it suffices to say that it may or may not be helpful to aggregate reports.
Please know I mention this not to evade an issue, but to illustrate a few pitfalls in diagnosis and resolution. With respect to support - this picture is a bit cloudy, too. Developers using the SDK(s) have access to certain support mechanisms, but these arrangements do not normally extend in an unbroken line from an end-user of a third-party product to the NDI developers and support staff 'without passing go.'
One of the reasons I monitor these forums is because it occasionally lets me identify something that is a legitimate engineering issue early on, without a lot of rigamarole ... but I do so gingerly, with due regard for 'orthodox' processes too - as their protocols have also been set up for good reasons. This all said, I had brought this thread to the attention of the official NDI support peeps earlier, and will pass along any helpful comments if they offer any. It may well be, though, that the advice is to go through regular channels, first talking with the providers in question. This often serves to filter out unrelated 'noise' (I do not mean this in a derogatory way) and isolate the relevant factors.
First, while I understand the temptation to reach that conclusion, I'm not at 100% certain that this really is "the same exact issue". It's entirely possible that it is, or perhaps the seeming similarities are just that. The profusion of gear and software mentioned in two reports don't make it easy to determine whether there is a common factor, or - if there is - whether different implementations by different developers may have made identical missteps, or whether this represents some unforeseen problem with the NDI SDK (the developers may not be using the same one, btw). I could go on, but perhaps it suffices to say that it may or may not be helpful to aggregate reports.
Please know I mention this not to evade an issue, but to illustrate a few pitfalls in diagnosis and resolution. With respect to support - this picture is a bit cloudy, too. Developers using the SDK(s) have access to certain support mechanisms, but these arrangements do not normally extend in an unbroken line from an end-user of a third-party product to the NDI developers and support staff 'without passing go.'
One of the reasons I monitor these forums is because it occasionally lets me identify something that is a legitimate engineering issue early on, without a lot of rigamarole ... but I do so gingerly, with due regard for 'orthodox' processes too - as their protocols have also been set up for good reasons. This all said, I had brought this thread to the attention of the official NDI support peeps earlier, and will pass along any helpful comments if they offer any. It may well be, though, that the advice is to go through regular channels, first talking with the providers in question. This often serves to filter out unrelated 'noise' (I do not mean this in a derogatory way) and isolate the relevant factors.
Last edited:
tlv1studios
New member
Thanks for that explanation, Steve. It was all very well put. I understand these are difficult issues to troubleshoot. I will continue to try and figure it out on our end but any help from you, others on this forum (and other NDI forums I've joined), and the developers would be appreciated. I've also reached out to Wirecast's Telestream. And again, I am willing to provide any detail necessary if it helps.
tlv1studios
New member
@SBowie, I've tested using a different switch - no difference. I've tried multiple apps, some M1 chip optimized, others running in Rosetta2 - no difference. I have not tried a different computer but what signals to me that this shouldn't be a factor is that the ISO recordings are jitter-free whereas the live/preview/recorded files are displaying these jitters.
I'm going absolutely nuts trying to narrow down the possible issues, but it appears to be beyond my setup. Any suggestions would be oh so greatly appreciated.
I'm going absolutely nuts trying to narrow down the possible issues, but it appears to be beyond my setup. Any suggestions would be oh so greatly appreciated.
I would like to add that we initially thought this was a networking issue as well. We were running a Mikrotik CRS-354 and have since moved to the Netgear AV switch and the issue persists. I'm open to running tests to help narrow down the issue. But at this point I'm, kind of lost as to what test to run next. None of our Computer or Network resources are anywhere closed to being maxed out when this issue occurs. It seems like latency is being injected after the preview window somehow and I don't really know how I would prove that.
tlv1studios
New member
@coritgmun Are all your cameras indeed set to 30 fps rather than 29.97? It appears like there may be an issue with NDI feeds of 29.97 fps resulting in duplicated frames. Someone noticed that when they took my jittery video and opened it in a video player that can progress frame by frame, there is a duplicate frame every 3-30 frames, which seems like the cause of the jittery video.
Last edited: