[Elphel-support] Fwd: ccam.cgi

[Andrey Filippov]

Hi Simon,

Thank you for asking about ccam.cgi compatibility.

Can you please describe what exact functionality do you need from ccam.cgi?
Maybe it is possible to modify your client software (and/or add some PHP
scripts to the camera) and use the current camera firmware?

You see, the ccam.cgi was rather tightly connected to the camera drivers,
together they were design to get parameters and serve images over the
network

ccam.cgi used traditional approach:
1 - get user parameters
2 - reprogram the sensor and/or compressor ( if the new parameters were
specified). In Most cases that required a complete reset of the internal
acquisition pipeline
3 - wait for the new image to appear in the buffer
4 - send image to the client (through the web server)

Unfortunately such approach was limiting the update rate - the
re-programming the sensor and camera acquisition modules required purging
the acquisition pipeline (starting with the sensor latency) ,  so several
(3-4) frames were lost, and the camera web server was locked for the
duration of the steps 1..4 for other requests.

 With the current (8.x) software we used a different method (see article in
LinuxDevices -
http://www.linuxfordevices.com/c/a/Linux-For-Devices-Articles/Elphel-camera-under-the-hood-from-Verilog-to-PHP/),
trying to minimize number of frames lost to re-programming.
Additionally
we sped up the step 4, images are now served by a dedicated fast image
server - imgsrv (listening on the camera port 8081), it gets up to
~10.4MB/sec over the 100mbps network.

Current drivers are aware of the sensor and compressor latencies for various
parameters, they change program sensor and  change the internal parameters
in sequence that match the image pipeline, it is possible to schedule
parameter change in the future. The pipeline approach made "current
parameters" non-applicable to the camera - for example "current exposure" or
"current image width" can be different in
 - i2c command queue (data to be sent to the sensor at the frame boundary
 - for the current frame being acquired in the sensor
 - for the frame being read in to the video buffer
 - for the frame being compressed in FPGA
 - for multiple frames being stored in the circular buffer, ready to be
recorded to the disk or to be sent over the network - as video or individual
images

This is why we had to change the camera programming interface. In order to
combine interface flexibility and high performance we decided to abandon any
fixed API (it would either limit the camera functionality or soon grow too
big and slow) and use efficient integration of the PHP running in the camera
- it uses fastCGI and custom extension to deal with camera-specific
functionality. We have several examples of PHP scripts that control camera
parameters through the web interface, imgsrv (http://camera_ip:8081) can be
used to acquire individual images.

Of course it is possible to install the legacy (7.x) firmware to the camera
- the one that still has ccam.cgi, but I hope it should be not that
difficult to migrate to use the newer functionality, please don't hesitate
to ask particular questions about it. The same functionality will be
available in the next model 373 camera too, there will be no legacy ccam.cgi
there.

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