Ok, I modified the code to print the time taken for each frame.
Indeed, what happened is that it seemed to slow down pretty bad for certain
frames
Eg.
Frame: 110 time taken: 0.0009679794311523438
Frame: 111 time taken: 0.001013040542602539
Frame: 112 time taken: 0.0014612674713134766
Frame: 113 time taken: 0.0010993480682373047
Frame: 114 time taken: 0.004855155944824219
*Frame: 115 time taken: 0.48161911964416504*
Frame: 116 time taken: 0.001965761184692383
Frame: 117 time taken: 0.0023725032806396484
Because of those bad frames, it slows down the entire frame rate.
So it is probably a packet resend problem.
Now for the bad news. I meddled with the packet resend settings and ended
up even worse off- now the packet error seems to occur practically every
other frame.
I don't even know how to get back to the previous settings.. Hopefully I'll
work it out..
On Fri, Dec 22, 2017 at 6:09 PM, Nial Peters <nonbiostudent@xxxxxxxxxxx>
wrote:
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>
<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.
