Difference between revisions of "Talk:Porting Theora to 353 cameras"

Revision as of 01:19, 3 March 2008

Ok, I started a new page on the Theora project in 353 cameras. I started with a global approach and a list of modules that need to be changed or replaced on the 353 model. Feel free to correct me or add suggestions as I'm not (yet...) an expert on Elphel cameras. I think the first step is to make an exhaustive list of the hardware blocks that need modifications and then detail what need to be done in each block. --JeremViewsurf 03:48, 19 February 2008 (CST)

As I understand your first need is not a streaming but producing a small video clip to be uploaded via FTP. This can be done more easy with minimal non FPGA modifications.

We will probably create a CVS branch for your port, to be able to test it we need to compile a standard 7.1.x firmware disabling everything sensor or FPGA related and change the FPGA bitstream. --Alexandre.Poltorak 07:53, 19 February 2008 (CST)

You mean that it should be possible that the system can handle software Ogg Theora encoding for a non real-time application such as producing small video clips ? I'm aware that it depends on the output resolution, framerate and length of the clip but does a 1 min 1024x768 @ 25fps clip for example can be processed in a reasonable delay ? I'll discuss with Viewsurf's development team in order to obtain more precise specs concerning video output (in terms of length, resolution, framerate and encoding delay acceptable) but if you can give me an idea of what the software part can handle, I would consider spending more time in soft Theora transcoding instead of FPGA design. --JeremViewsurf 03:37, 20 February 2008 (CST)

No, sorry i was not speaking of transcoding. It would take too much calculation power and is not possible on the camera's CPU. The Theora encoding should be done in FPGA. What i was speaking about is the software part.. I think you do not need a streamer for the first steps. You only need to generate a clip in the FPGA memory, and upload it to a FTP. --Alexandre.Poltorak 08:32, 20 February 2008 (CST)

Some questions concerning changes in the FPGA :

• Is it necessary to keep histogram and timestamp blocks in a design which supports Theora only ?
  • I believe the camera will be rather crippled w/o those features--Andrey.filippov 10:24, 25 February 2008 (CST)
• Is it possible to keep channel 0, 1 and 3 design without changes in the memory controller ?
  • Theora implementation used different (more advanced) memory controller that the JPEG, it was getting 95% efficiency at Theora data structure, so you need Theora memory controller. But if you mean by "Channel 0 design" the gamma tables and histograms - yes, they probably could be ported (with some changes, of course). As for channels 1 and 3 - similar are available in Theora 333 also--Andrey.filippov 10:24, 25 February 2008 (CST)
• The 353 design uses 2 DMA fifos between the compressor and the system interface instead of one in the 333 design. Is it possible to keep only one 333 DMA fifo in the final design ?
  • Yes, of course - but this is so minor difference. The more important is that in Theora that FIFO could make the compressor wait if ETRAX DMA is not ready - at the beginning of the frame in theora there is a data "burst".--Andrey.filippov 10:24, 25 February 2008 (CST)
• In the 353 design, all signals and blocks I/O concerning 90° phase clock are commented. Is it possible to uncomment them in order to restore the clock ?
  • Maybe yes, more likely no. 353 and 333 use different FPGAs.--Andrey.filippov 10:24, 25 February 2008 (CST)
• Motion compensation seems not to be implemented in the Theora compressor yet. Is it possible to add this feature later in the compressor block without major changes in the final design ?
  • No, I'm afraid that is not possible - I believe we need faster FPGA for that and likely faster/wider memory.--Andrey.filippov 10:24, 25 February 2008 (CST)

--JeremViewsurf 02:43, 25 February 2008 (CST)

I'm currently working on the FPGA control register and I have a question concerning the I2C pads controlled by the control register (via dcr[16:21]). In the 333 design there are 2 I2C "channels" : (sda0,scl0) and (sda1,scl1) and only one on the 353 design. Is it possible to keep a single i2c channel on the new design ? In other ways, what is the purpose of the i2c "channels" in each device ? --JeremViewsurf 03:19, 3 March 2008 (CST)