[Elphel-support] Temporarily disable the digital compass on 353?

[Andrey Filippov]

On Mon, May 31, 2010 at 12:12 PM, Andrey Filippov <andrey at elphel.com> wrote:

> Unfortunately I just noticed a bug in the software - when you adjust image
> quality there is a delay between that in  the FPGA and in the frame header.
> I'll work on it.
>
>
Phil,

 I fixed that old bug that effectively disabled caching both FPGA
quantization tables and file header ones, so fixing it should improve
performance even if you do not update quantization quality - because of that
bug each output frame required re-calculation of the quantization tables
that are appended to each JPEG/JP4 compressed frame. The software was
designed to have an eight quantization  table cache, so if the current
compression quality value is one of the 8 least recently used ones - no
calculation will be required, just copyiing.

I would not recommend (yet) to use the CVS code - it is now actively being
updated, so it may have some other bugs. Additionally the current code in
CVS has debugging option enabled (in file c313a.h) -- that also reduces
performance that is so important in your application. The required bug fix
in the tables is in just one file :

http://elphel.cvs.sourceforge.net/viewvc/elphel/elphel353-8.0/os/linux-2.6-tag--devboard-R2_10-4/arch/cris/arch-v32/drivers/elphel/quantization_tables.c?view=log

and it is possible to replace it in older (stable) software release and
recompile.

This fix covers also the FPGA quantization tables - the ones that are use
during actual compression. FPGA code is designed to have room for 8 versions
of the table (corresponding to last 8 used quality values). Copying a table
to FPGA takes some time, switching pre-loaded between FPGA tables is very
fast. If the driver finds out that a new table is needed it transfers the
data to FPGA several frames ahead of the time (to allow other computational
activities in the meantime) and programs hardware (FPGA) sequencer to switch
the tables at the required frame. Because of that bug only table 0 was used,
without any switching, so FPGA compressor was using the new table as soon as
it was being downloaded to the FPGA - some 3 frames ahead of time, and sure
enough that data did not match the quantization tables atatched to the
compressed images.  That was causing three wrong frames for each compression
quality change. Now it is all corrected and it is safe to change compression
quality while recording - there will be no wrong frames.

Large circular buffer (19MB) gives software some time to adjust compression
quality if the buffer is getting close to be overrun, I think it is possible
to implement such control in just the PHP code of camogmgui, later moving it
to the camogm application itself. For the best effeciency the compression
quality should be dynamically adjusted while trying to reuse valiues set
previously, when using just 8 values for the compression quality switching
between them will not require any re-calculation or transferring data to
FPGA.

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