Hi,
This may be irrelevant to your problem, but some years ago when I was using
Aravis with a FLIR SC645 thermal camera I found that occasionally a frame would
take a huge amount of time to transfer compared to normal. It turned out to be
due to packet resend requests. As soon as a packet was dropped and Aravis
requested a resend, the camera seemed unable to cope, sometimes freezing
completely and needing to be reset. I found that disabling packet resend
requests in Aravis resulted in a more reliable throughput, as long as you can
cope with a frame being occasionally lost. I'm not sure how you do this with
the Python interface (and I may also be well out of date with the current
Aravis release) but in C it was using g_object_set(camera->stream,
"packet-resend", ARV_GV_STREAM_PACKET_RESEND_NEVER, NULL)
As I said, this didn't happen very often, so perhaps it is possible that for
small value of numFrames you don't see this problem, but for larger numbers it
is occurring for one or two frames and slowing things down? You could easily
test this by recording the time taken to retrieve each frame and see if it is
just a few frames that are slowing things down or whether there is an overall
reduction in throughput for large numFrames values.
Cheers,
Nial
On 21/12/17 10:12, Emmanuel Pacaud wrote:
Hi,
Hi,
Le ven. 15 déc. 2017 à 14:52, Saurabh Chatterjee
<saurabhsaurc@xxxxxxxxx><mailto:saurabhsaurc@xxxxxxxxx> a écrit :
For a low value of numFrames ( say 100 ), I get frame rate of 60
For high values ( say 600+ ), the frame rate goes down to about 25 or so..
any idea why that might be happening?
Did you check the CPU and memory consumption of your software ?
How did you setup the acquistion framerate ?
Cheers,
Emmanuel.
