similar to: FPGA implementation in the camera

I'm considering implementing the Theora format in the FPGA of the new camera. The previous model (Elphel 313 - http://www.elphel.com, https://sourceforge.net/projects/elphel) had smaller FPGA and was able to produce just motion JPEG utilizing 97% of the resources. The new (model 333) camera uses 3 times bigger FPGA (and also faster), it also has increased frame buffer and system memory.

I'm considering implementing the Theora format in the FPGA of the new camera. The previous model (Elphel 313 - http://www.elphel.com, https://sourceforge.net/projects/elphel) had smaller FPGA and was able to produce just motion JPEG utilizing 97% of the resources. The new (model 333) camera uses 3 times bigger FPGA (and also faster), it also has increased frame buffer and system memory.

Today I've got first video clips made by the camera and compressed "on the fly" - 1280x1024x30fps. Image quality is far from perfect - I don't have yet any way to preview images, and a single acquisition still requires a bunch of commands. So I'm really close to have a camera that will be able to serve the Ogg/Theora streams, now but will it be possible to play it on a PC? I

Andrey posted the following update at his sourceforge web site. I'm sharing it here because I think it is fascinating to see the progress in his FPGA implemention of the Theora codec as it happens. John <snip> Wrote code and partially simulated compressor_two module with submodules. It gets fixed-width (12-bits) "pre-tokens" from the frame buffer in the coded order

Hi, So I have almost completed a new VP3 decoder implementation. In the course of doing so, I have encountered something odd about macroblock coding. As a quick overview, VP3 has a notion of fragments (8x8 pixels) and superblocks (32x32 pixels, 4x4 fragments). These apply to each individual plane (e.g., a 64x64 video will have 4 Y superblocks and 1+1 C superblocks, 64 Y fragments

Good day! I create diagram of encoder process. Using it i create implementation of encoder in FPGA (Xilinx/Altera). Please critique it. Is there missing stages? Here is blog http://developer-fpga.blogspot.com/ Here is picture of encoding stage 1 https://lh4.googleusercontent.com/-NV8o9DG3jvE/TYjYXr-dYGI/AAAAAAAAAos/U06O-YvhSI0/s1600/stage1.jpg Here is picture of encoding stage 2

Thank, Timothy! I add this stages. About RLE: I have one more unresolved stage. Mike Melanson wrote in "VP3 Bitstream Format..." about RLE using: "* Zigzag Ordering: After transforming and quantizing a block of samples, the samples are not in an optimal order for run length encoding. Zigzag ordering rearranges the samples to put more zeros between non-zero samples." If we pass

Hi , > df Session_Setup DCT FwdDataVols_bin counts Comp 1 User_Initiated NoRLL 1 5058 User_Initiated+NoRLL+1 2 User_Initiated NoRLL 2 584 User_Initiated+NoRLL+2 3 User_Initiated NoRLL 3 191 User_Initiated+NoRLL+3 4 User_Initiated NoRLL 4 128 User_Initiated+NoRLL+4 5 User_Initiated

Hi , > df Session_Setup DCT FwdDataVols_bin counts Comp 1 User_Initiated NoRLL 1 5058 User_Initiated+NoRLL+1 2 User_Initiated NoRLL 2 584 User_Initiated+NoRLL+2 3 User_Initiated NoRLL 3 191 User_Initiated+NoRLL+3 4 User_Initiated NoRLL 4 128 User_Initiated+NoRLL+4 5 User_Initiated

Df contains Session_Setup DCT RevDataVols_bin counts comp 1 Session_Setup RLL 1 NA Session_Setup+RLL+1 2 Session_Setup RLL 2 NA Session_Setup+RLL+2 3 Session_Setup RLL 3 NA Session_Setup+RLL+3 4 Session_Setup RLL 4 NA Session_Setup+RLL+4 5 Session_Setup RLL 5

Hi, just a small follow up of recent discussions about Elphel's JP4 format. I'm working with Andrey and fellows from Elphel to improve support for JP4 format in the context of Elphel's Apertus project (http://www.apert.us). As posted by Basil, on http://wiki.elphel.com/index.php?title=JP4 there is plenty of information about the format and how to post process it to get back your real

Andrey Filippov reports at his sourceforge website that he is 50% of the way towards the implementation of ogg theora in a FPGA, and has a goal of reaching 100% (leaving out motion compensation) by Dec. 14, 2004. These are some of the tasks he has completed most recently: Added 8-point forward DCT following the algorithm suggested in Theora specs. 2004-10-31 22:17 Created 2-d IDCT according

Andrey Filippov reports at his sourceforge website that he is 50% of the way towards the implementation of ogg theora in a FPGA, and has a goal of reaching 100% (leaving out motion compensation) by Dec. 14, 2004. These are some of the tasks he has completed most recently: Added 8-point forward DCT following the algorithm suggested in Theora specs. 2004-10-31 22:17 Created 2-d IDCT according

Raphael, Some 15 years ago I implemented limited functionality Theora in our cameras FPGA (it took me 6 month of hard labor), and then gave up - it is a very crowded space and it is difficult to compete with more advanced codecs. And for our other work we anyway need almost raw image data, so we are using JPEG-based JP4 format (https://community.elphel.com/jp4) that we originally developed for

Hi, Is somewhere alghorithm description of encoder process implemented in libtheora? May be some drafts? May be frame dataflow throw encoder stages? PLEASE -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/theora/attachments/20110318/c3e8e109/attachment.htm

Hi I'm trying to make sense of the macroblock coding modes in section 7.4 of the Theora spec. The text in the specification is: (d) For each consecutive macro block in coded order (cf. Section 2.4) indexed by mbi: i. If a block bi in the luma plane of macro block mbi exists such that BCODED[bi ] is 1: A. If MSCHEME is not 7, read one bit at a time until one of

On Sun, Apr 10, 2005 at 01:14:14PM +1000, Conrad Parker wrote: > On Fri, Apr 08, 2005 at 12:45:08PM -0700, Ralph Giles wrote: > > Conrad, > > > > Small buglet with the 0.9.1 liboggz release (go dude!) > > > > http://thaumas.net/~giles/xiph/elphel/clips/elphel_00017.ogg causes a > > float exception in oggzinfo when it tries to calculate the bitrate. It

Andrey and I were having a conversation off list, forwarding relevent bits of the last response from Andrey for public reference. --- begin forward --- On Mar 31, 2005 9:22 PM, Ralph Giles <giles@xiph.org> wrote: > On Thu, Mar 31, 2005 at 06:46:06PM -0700, Andrey Filippov wrote: > > > > BTW, you asked about padding theora packet data to a byte boundary. I > > >

/*Determines the number of blocks or coefficients to be skipped for a given token value. _token: The token value to skip. _extra_bits: The extra bits attached to this token. Return: A positive value indicates that number of coefficients are to be skipped in the current block. Otherwise, the negative of the return value indicates that number of blocks are to be ended. 0 will never be returned,

Conrad, Small buglet with the 0.9.1 liboggz release (go dude!) http://thaumas.net/~giles/xiph/elphel/clips/elphel_00017.ogg causes a float exception in oggzinfo when it tries to calculate the bitrate. It fails to measure the duration and tries to divide by zero. :) There may well be something wrong with the file, although oggz-validate doesn't complain. Also, the configure script