[aravis] Re: Make num-buffers a parameter
- From: Andrew Straw <strawman@xxxxxxxxxx>
- To: aravis@xxxxxxxxxxxxx
- Date: Tue, 22 Apr 2014 14:25:15 +0200
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:
