FLIR BlackFly frames stuck in buffer filling it up, using SpinView

Hi everyone,
I’m a Physics undergrad doing Neuro-Biology research using computer vision. We are using two FLIR Blackfly cameras, exact model is: BFS-U3-244S8M-C, and use SpinView for video acquisition.

We have a problem where above a certain FPS(6 to be exact) and image compression quality, frames are getting “stuck” in the buffer and very quickly pile up and we have to stop the recording. Another issue is that sometimes after some work done, say we used 6fps, we can now only use 4fps without this issue occurring.

FLIR support is of no help, it sounds like the support staff doesn’t have a clue as to what’s going on. What’s baffling about it is the fact that I know that this is supposed to be a RAM issue as the CPU and SSD barely use 10-20% of their resources for this while I can see the RAM getting filled up in task manager, but when I switch cameras everything seems to be fine(up to a certain point, let’s say 8fps and then it’s getting buffer issues again).

Has anyone had this happen to them? Can I fix this by having faster RAM or operate it on a quad channel setting?

Thanks in advance, I’ll be sure to hang around and show this place to other students, looks like we can learn a lot.

I assume that you are trying to record the movies to the SSD?

I would think the RAM must be filling up because the SSD is not fast enough, so I don’t think faster RAM is likely the solution here. If you are recording from both cameras at once at full frame that is 24M pixels * 6 FPS * 2 = 294 mega bytes / second (assuming 8 bit images w/o compression) which might be about what your SSD is rated for? Your SSD may also be slower than you expect if it is fragmented, etc… And there might be additional bottle necks if you are trying to write two files at once.

Yeah I’ve tested it with faster RAM(same exact SSD) an it’s no solution.
I’m using one camera at a time and our SSD can do a lot faster than 300MBps, it’s tested for 3GBps write and read. I can also see in task manger that during these test the SSD doesn’t try too hard, usually goes up to 20-30MBps for short bursts during the acquisition. The SSD is also regularly trimmed(you don’t defrag an SSD) and overall it’s a brand new PC.
Also, if we choose uncompressed there’s no problems even at full camera specs, at 15 fps, it doesn’t have any buffer issues. This is huge files compared to mjpeg so the SSD is not the problem too.

The professor says the camera did fine with these parameters when he did his first experiment, 2014-2018 with PCs that are now dated(this issue is the same with the new camera too).

We’re using mjpeg compression, without it it runs fine but we’re getting huge files. Tbh I’d be fine with doing uncompressed and then letting the CPU encode it, but the files turn out huge(at least 3TB) and the professor says it’s a last resort since it’ll take too much time and backups and files transfers(we have different PCs for DAQ and for analysis) will be a pain too.

Anyway, this is really baffling for me, really really baffling for me. This shouldn’t be such an issue. I would say maybe it’s the CPU lagging with the compression, taking its time, and I should maybe render on a GPU, but task manager says CPU is barely at 10% workload and this is an i9 10900k.

I’m really at a loss here.

Is SpinView multi-threaded? Maybe it is only using a single core?

1 Like


Try setting the SpinView priority to high or realtime. We have eliminated lag and buffer issues with similar applications.



1 Like

It’s probably single threaded, I think I’ll have to make my own application using spinnaker c++

I will try that, thanks.

Curious if you resolved the buffering issue?