[aravis] Re: Make num-buffers a parameter
- From: Patrick Doyle <wpdster@xxxxxxxxx>
- To: aravis@xxxxxxxxxxxxx
- Date: Tue, 22 Apr 2014 09:00:04 -0400
Hmmm... that's an interesting thread. The behavior reported by John
Stowers matches the symptoms I've seen with my setup as well. Tom
Cobb suggested increasing the network receive buffers to 1Mbyte and,
in the limited testing I performed last week, that made a HUGE
difference, especially where the default buffer size was 160K on my
system. My 640x480 frames require 300K, so if the Aravis receive
thread gets held off for longer than a frame time, I would receive 1/2
frame and then issue resend requests for the other 1/2 frame. If the
CPU was overburdened (as I know it is in my case when running at
30fps, simultaneously analyzing frames and compressing them) packets
would get dropped, resend requests would get sent, things would pause
for varying amounts of time, and things would work great for varying
amounts of time.
I like your idea of processing partial frames, if I wanted to obtain
the absolute minimum latency possible. Fortunately, my system doesn't
have that stringent of a latency requirement (yet!). As long as I can
keep the end-to-end latency below 3 frames or so, I should be fine.
I've still got some work to do on my end, but if my processing ends up
chewing up 35 of the 33ms per frame available for 50 frames in a row,
I would rather drop frames once in a while than operate on frames that
are 50 frame-times out of date.
--wpd
On Tue, Apr 22, 2014 at 8:25 AM, Andrew Straw <strawman@xxxxxxxxxx> wrote:
>
> On 22 Apr 2014, at 2:07 PM, Patrick Doyle <wpdster@xxxxxxxxx> wrote:
>
>> Apologies for the generalities of this email -- I don't have access to
>> the source code at the moment (computer is in the shop), but the mind
>> still runs on and on...
>>
>> When I do regain access to my development platform, I would like to
>> make the number of frames that can be buffered a runtime parameter
>> instead of a compile time constant. Going from memory, I seem to
>> recall that there is a compile time constant, set to 50, that
>> determines the number of frames that the gstreamer thread will
>> buffer.
>>
>> What are the implications (if any) of making this a runtime property
>> (obviously with a default value of 50).?
>>
>> What are the implications of setting it to 1 or 2 at runtime?
>>
>> I need to minimize the latency in my system and would rather drop
>> frames (now that I can trust the timestamps from my Blackfly cameras)
>> than have them buffer up.
>
> I will also re-send a suggestion of mine from the distant past (
> //www.freelists.org/post/aravis/Recovered-Packet-Numbering,2 ):
>
>> Would it be advantageous for reducing latency to turn off the ordering? Is
>> there an option to do this and leave the re-ordering to higher level
>> software?
>
> Note that I think your question and my suggestion are done without testing
> the effects of disabling resending. I would think this would prevent
> reordering frames but have not dug into to the code to verify.
>
> Additionally, for reducing latency, one could imagine image processing on the
> incoming packets even before all packets to complete a frame have arrived.
>
> -Andrew
Other related posts:
