[aravis] Re: Debugging latency & long pause issues with Blackfly camera...
- From: Patrick Doyle <wpdster@xxxxxxxxx>
- To: aravis@xxxxxxxxxxxxx
- Date: Wed, 16 Apr 2014 09:02:45 -0400
Thanks Tom,
That looks like a very useful tip. I'll see if/how much/ it helps
once I get past my "what do timestamps from the BlackFly camera really
mean?" quandary.
Speaking (writing?) of that quandary, I instrumented the
arv_gvsp_packet_get_timestamp() function to dump out raw timestamps as
they are received from the camera. (In hindsight, I wonder if the
arv-camera-test tool would have provided me the same information --
I'll go check that next).
What I found was that there were, on average 819200 ticks between each
frame, when I configured the camera for 30 frames/second, and that the
ticks/frame ratio scaled linearly for different frame rates I tried.
That would correspond to a tick frequency of 24.576 MHz. Which does
not correspond to the 125 MHz tick frequency reported by the camera.
In addition, there are not _exactly_ 819200 ticks between each frame,
which seems odd to me -- it varies a bit from frame to frame. That
wouldn't seem odd to me if the tick frequency were 125 MHz,
correlating to a 125 MHz clock for the ethernet interface, because I
wouldn't expect the video clock to necessarily be synchronized to the
ethernet clock. However, this makes me thing there are 3 asynchronous
clocks on the camera: a video clock, a 24.576 MHz timestamp clock, and
a 125 MHz ethernet clock.
I wonder, for those of you with more video experience than I, is
24.576 MHz a common clock frequency for video applications?
Also, I noticed that the lower 32 bits of the timestamp never (based
on a small handful of samples) go above 0xBB800000. It seems like,
once the timestamp counter reaches 128 seconds (assuming a 24.576
clock rate) the lower order 32 bits wrap around to zero and the higher
order bits increment.
Also, it seems as though neither of the timestamp counters (HIGH or
LOW) increment when I don't receive video frames from the camera.
(For example, they are both at more or less the same value this
morning as they were last night).
I'm going to go see what BlackfFly documentation I can find about
timestamps, perhaps play with the Blackfly API and see if I see
similar behavior, perhaps instrument Aravis some more (or learn that
arv-camera-test has all of the instrumentation I need), and then
propose some possible changes to Aravis (see below).
In the mean time, I'd appreciate any feedback folks might have
regarding whether any of this sounds plausible. (Let's pretend that I
manage to collect enough data to validate it all).
Assuming that the data I collect shows that the camera does, in fact,
run with a 24.576 MHz timestamp frequency, and that the lower 32 bits
wrap around every 128 seconds (incrementing the high order 32 bits at
that time), what would be the best way to deal with this in Aravis --
keeping in mind that I really want camera timestamps for my
application, as opposed to timestamps at which packets were received
over the network.
I can think of 3 possibilities:
1) Handle timestamps from BlackFly cameras as a special case within
the Aravis framework.
2) Extend the Aravis framework to allow it to report raw timestamps
received from a camera and write my own gstreamer plugin to convert
Blackfin timestamps to ns.
3) Do something smarter suggested by one of you.
--wpd
On Wed, Apr 16, 2014 at 4:01 AM, <tom.cobb@xxxxxxxxxxxxx> wrote:
> I found that on some systems I had to increase net.core.rmem_default and max
> using the instructions in this technical note:
> http://www.ptgrey.com/support/kb/index.asp?a=4&q=354
>
> Thanks,
> Tom Cobb
>
>> -----Original Message-----
>> From: Patrick Doyle [mailto:wpdster@xxxxxxxxx]
>> Sent: 15 April 2014 13:39
>> To: aravis@xxxxxxxxxxxxx
>> Subject: [aravis] Re: Debugging latency & long pause issues with
>> Blackfly camera...
>>
>> Hmmm… I don't think that will address my particular issue. It appears
>> that I am not receiving some packets from the camera and that is
>> leading to problems. I need to insert a gigabit ethernet sniffer in
>> the loop to determine if the camera is not sending the packets (I
>> doubt this is the problem), the switch is dropping the packets (I don'
>> think this is the problem either), or my embedded board is dropping
>> the packets on receipt (I'm guessing this is the problem).
>> Unfortunately, my hardware doesn't support jumbo packets, so there is
>> ample opportunity to drop packets.
>>
>> I remain confused by the "do-timestamp" notion. I naively assumed
>> that "do-timestamp=true" meant that the gstreamer pipeline would use
>> camera timestamps. Now I see that it means the opposite.
>>
>> For my application (robot navigation), I need the camera timestamp,
>> which I hope correlates very strongly with the time at which the image
>> frame was captured.
>>
>> What is it about "do-timestamp=true" that makes things work with your
>> blackfly camera?
>>
>> --wpd
>>
>>
>> On Tue, Apr 15, 2014 at 4:32 AM, Emmanuel Pacaud <emmanuel@xxxxxxxxx>
>> wrote:
>> > Hi,
>> >
>> > Le lundi 14 avril 2014 à 21:53 +0200, Emmanuel Pacaud a écrit :
>> >> > I'm not asking that anybody solve this (although, if you've seen
>> this
>> >> > sort of thing with the Blackfly, or other cameras and can tell me
>> what
>> >> > to fix, you would have my eternal gratitude), but if anybody has
>> some
>> >> > suggestions as to what I might look at, or what tools I might use,
>> to
>> >> > diagnose these pauses, I would be grateful.
>> >>
>> >> I have a blackfly camera with which I face some troubles similar to
>> >> yours. I think it's due to the fact the register giving the Time
>> Tick
>> >> Frequency returns a wrong value. And this value is used to compute
>> the
>> >> image buffer timestamps.
>> >
>> > I've changed the viewer in git master to always use host time for
>> buffer
>> > timestamp. It fixes issues I was seeing using my blackfly camera.
>> >
>> > Using the gstreamer plugins, do-timestamp=true also allows to work
>> with
>> > a blackfly camera. It looks like there is around 100ms of latency in
>> the
>> > following pipeline, but I think it comes from the pipeline itself,
>> not
>> > aravissrc element:
>> >
>> > gstreamer 0.10 version:
>> >
>> > ./gst-aravis-launch aravissrc do-timestamp=true ! video/x-raw-
>> gray,bpp=8,depth=8 ! ffmpegcolorspace ! autovideosink
>> >
>> > gstreamer 1.0 version:
>> >
>> > ./gst-aravis-launch aravissrc do-timestamp=true ! video/x-
>> raw,format=GRAY8 ! videoconvert ! autovideosink
>> >
>> > Cheers,
>> >
>> > Emmanuel.
>> >
>> >
>
Other related posts:
