[Elphel-support] Elphel performance, Framerate / JP4

Andrey Filippov andrey at elphel.com
Sun May 23 12:19:39 PDT 2010


Hello Andreas

There are several factors that can limit the frame rate

First is the sensor itself, at full resolution the maximal frame rate is
slightly less than 15 fps, when the senor is in free-running mode (not
triggered) and the exposure is less than 1/15 sec

When you run sensor from the external (for the sensor, it can still be
FPGA-based timer as in your case) the maximal frame rate is lower. The frame
period is increased by 8 scan lines (about 35 microseconds each) _plus_ the
exposure time. If you have enough light and exposure time is around 1/1000
that period increase is not high, but it is still not zero.

Next goes the FPGA compressor, that itself uses known number of cycles
regardless of compression quality. In JPEG (and JP46 also - see
http://community.elphel.com/jp4/jp4demo.php ) compressor needs 3 system
clock cycles per image pixel (it needs 2 cycles, buit in these modes number
of compressed pixels is 50% more than image pixels, so 2*1.5=3). In the JP4
(not JP46!) mode there is no increase in compressed pixels from image ones,
so the FPGA uses 8 cycles/pixel.

With the system clock running at 160MHz that results in
1) JPEG, JP46 - 53MPix/sec
2) JP4 - 80 MPix/sec

And these numbers apply to the whole frame, the pixel data is buffered so it
is OK that sensor pixel rate is 96MHZ (average is about 75 fro the full
frames, lower fro smaller ones). Compressor can fall behind during
compression, it just needs enough time to finish the frame before the start
of the next one.

After that data is compressed and transferred into 19MB buffer in the system
memory - you can examine the data there with  camvc - press stop button and
navigate through the buffer, each frame will have the time stamp. It seems
you have the problem with buffer overrun - camogm can not record data at the
rate the FPGA is providing it. There is some difference between different
JP4* flavors in the compression qulaity/efficiency but the main difference
is at the FPGA compression stage (53 vs 80 MPix./sec)

As you have buffer overrun, the most important thing to check is just raw
MB/sec you can get while recording on your system (provided you use MOV
format that currently has the lowest CPU overhead). Our measured data shows
that with the fast HDD (internal ATA or external SATA) the ETRAX SOC can
provide approximately 16MB/sec of sustained recording. So I would just
measure this number in your setup as the next troubleshooting step.

Andrey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://support.elphel.com/pipermail/support-list_support.elphel.com/attachments/20100523/99063266/attachment-0002.html>


More information about the Support-list mailing list