using the videw_preview

Vadim said:

- when i use the old version this is what calls the fuctions

process_image( (void*)(frameBuffPtr->frame.frameBufferPtr), 320, 720, 100, 200 );

the problem is that they dont go until the end of the screen but only 5 cm til it (image add (the function not working where the red squer points) http://img184.imageshack.us/my.php?image=snapshot20090105uc7.jpg )

to over come this problem i change the yRows from 320 to 380 but is it a soulution?

i belive i found the answer to that question, i can change it to 576 and change in the punction from *3 to *2 as it used in the newer example.

but still your example consurn only the NTSC standart while it can also be a PAL, in the new example it was easyer to see it.

but still i dont understand why we should moltiplay it by 2:

for( xx = screenshift*2; xx < (((yRows * xPixels)*2)); xx+=1 

i'll be glad if you answer the rest of my questions

Please help me

Thank you.

- another thing that i wanted to know is the purpese of this:

*L2WBINVregPtr = 0x1; //initiate a writeback/invalidate to all to the L2 cache

while( *L2WBINVregPtr != 0);

In this example, if I recall correctly, the front end video driver uses a direct memory access to store the video input to DDR2, and the back end video driver also uses a DMA to pull that same data from DDR2 for display.  Because you are performing an intermediate processing step that brings the input image into cache for processing, you now have a cache coherence problem, i.e. the contents of cache do not match the contents of the DDR2.  The code above is a way of performing a write back invalidate, which basically sends the new image back to DDR2 from cache.  Now when the vpbe driver accesses this memory it will be current.  Cache is a confusing topic at first (for me at least), I would recommend checking out app note spru862 to get a better explanation.

As far as the luma only/luma & chroma question, this example brings the images in as 4:2:2 YUV format.  YUV is luma, blue chroma, red chroma, I forget the order.  The 4:2:2 means that you have two luma samples for each chroma pair sample.  The data is stored (again I forget the blue/red order, double check this): chroma1_b, luma1, chroma1_r, luma2, chroma2_b, luma3, ...

So you can see that incrementing by 1 will operate an every pixel, while starting with an offset of 1 and incrementing by 2 will operate on only luma. 

Any help?

Sorry for the delay here, I was out of the office last week so I did not see this post until today.

For the image height value issue I believe you are correct that this would be a PAL issue, I don't do much work with PAL here so pretty much everything is NTSC therefore I assumed the height of the image will be 480 pixels.

Matt is also correct on the cache and the luma/chroma explanation, the difference is the rate at which you increment to either work on every byte in the image (all values, i.e. xx+=1) or on every other byte (only luma or chroma, i.e. xx+=2). For every other byte depending on your starting value you will either have all luma or chroma, the +1 on the 'xx=screenshift*3+1' is offsetting the start by a byte so that you hit all luma instead of all chroma.

You may want to try making modifications to the code, adjusting the offsets and increment rates and such, to see how the output image reacts, if you play with the numbers in the processing function you can get different results and that should help you to better understand what each piece is doing.