[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[video] Re: Video Compression Unit (OpenCores)



On Monday 31 March 2003 17:28, you wrote:

> The result generated by FDCT sometimes has an offset of 1, so I think that
> was fine.  Can I have some questions about JPEG encoder? I am really
> appreciated for your replying.
>1) How do you hook-up the RGBtoYUV unit to
> FDCT? Since the output for the RGBtoYUV is 10-bit width and input of FDCT
> is 8-bit

Simply ignore the 2LSBs from the RGB2YUV converter.
However where you hookup the RGB2YUV converter might be an issue.
The JPEG encoder needs a memory to work from, because images are usually 
captured a line at a time, whereas the JPEG's DCT unit works on 8x8 pixel 
blocks. So you need to store an image (or part of an image) and then start 
working on it. To save on memory size you can store the image as YUV 4:2:2 
instead of RGB.

Also note that the RGB2YUV outputs 4:4:4, you need to discard every other U 
and V samples.

> 2) How to hook-up the Huffman encoder with the RLE module?

See the JPEG encoder code, it is already hooked up.

> Who is
> reposonbile for choosing the appropriate huffman table (DC & AC Luminance,
> DC & AC Chorminance)

You are (or better the controller is).

Note that currently only the default huffman tables are supported. I couldn't 
(and still can't) figure out how to make them programmable. However for most 
applications they should be ok.

> 3) Do you process the U & V elements followed by Y
> elements?

That's all up to you. The JPEG encoder works on 8x8 pixel blocks. How you 
generate those blocks is up to you (well they need to be from the same frame 
and the same color). The least memory demanding is to process 1 block Y, 1 
block U, and then 1 block V (where a block is 8x8pixels). However the 
simplest (and probably the best) might be to process a complete frame Y, then 
a complete frame U, and finally a complete frame V. This requires you to 
store a complete image though, probably using an input ping-pong memory.

> What is the ratio of them? 4:2:2 ? 

That's up to you. You can do any combination you want.

Richard


> Sorry for taking your time to review those questions. Thanks !!
> 
> Tsung-Chi
> 
> -----Original Message-----
> From: Richard Herveille [mailto:richard@asics.ws]
> Sent: Monday, March 31, 2003 5:34 AM
> To: tlin@cae.wisc.edu
> Subject: Re: Video Compression Unit (OpenCores)
> 
> 
> 
> Can you tell me exactly what you simulated.
> I simulated parts of the encoder and they showed up ok. I also simulated
> the 
 entire JPEG encoder, and it shows up ok too.
> 
> Note that small differences in the results are allowed. The JPEG specs say
> the 
 the combined encoder/decoder may be off by 1lsb.
> 
>
> > Hi,
> >
> > I am interested in your project of building a video compression unit.
> >  So far I used your testbench to simulate the part of "FDCT", "QVR",
> > and "RLE" but seems there are some errors during simulation.  The
> > result of Amplitude doesn't match the output_check_list in testbench
> > and showup lots of error_counts.  I am wondering that did you get the
> > same simulation result as I described above?  Thanks !!!
> >
> >
> > Tsung-Chi
>
> 
> 


--
To unsubscribe from video mailing list please visit http://www.opencores.org/mailinglists.shtml