Data in one frame formed by two fields deinterlaced under PAL standard

hanks tom,

VPFE output image file will contain only pixels.  There is no other data.

Please provide complete algorithm that you used for swapping pixels so that I can figure out what might be going wrong.

~Nag

Thanks,Nag

the code is like this:

for(i=0;i<inArgs->height/2;i++)

      for(j=0;j<inArgs->linelenth;j++) {

           temp=bufs[curBuf][i*(inArgs->linelenth)+j];

          bufs[curBuf][i*(inArgs->linelenth)+j]=bufs[curBuf][(inArgs->height-1-i)*(inArgs->linelenth)+j];

          bufs[curBuf][(inArgs->height-1-i)*(inArgs->linelenth)+j]=temp;

   }

Besides,in the encodedecode demo's capture thread ,there are some extra rows for one frame if the CaptureOperation is CAPOP_SMOOTH.Here i want to know if these extra rows contain any data?Are they be sent to video thread or codec for processing?Thanks!

My guess here is that the problem is one of buffer management and that one of two things is happening...

1) You are accessing a buffer which is still being written to by the VPFE hence some of the image data you are flipping is then being over-written.

2) The display is accessing the same buffer that you are writing to at the same time you are accessing it causing parts of different images to be displayed.

Make sure that you are not reading the same buffer to which the VPFE is accessing and also that the buffer you are working on is not the one currently being displayed.

BR,

Steve

Thanks,Steve

but I don't quite agree with you.In the demo,one frame data were sent to codec,my code is in there .After processing,then send the data to display.And bisides,if it is like what you side ,I think the unchanged data should not be at the middle part of the picture.

All I can say is that if you are really inverting the data correctly and accessing the buffers correctly then the display WILL show the correct data. There is no way for the display hardware to take part of one buffer and part of another, which is the only way you can get this middle image artifact.

The region where the unchanged data is visible would be timing dependent if you are reading and writing to the wrong buffers.

A simple test is to add a delay just before you do the inversion. If adding a delay changes the position of the error then you have buffer overlap.

BR,

Steve

Thanks Steve ,for your advise.I will try it,and check my code carefully to make sure whether I read or write the buffer incorrectly.Thanks again.

Steve,

I check my code carefully ,and I still can't solve the problem.Here I want to show you the picture i got:

The part between the two red lines is unchanged .I add some rows to height/2,first 100,the part became taller,then changed to 50,a litter taller,I changed to 38,28,it seems no change on tall.

I change my code like this:

for(i=inArgs->height/3;i<inArgs->height/2;i++),the rest remains the same,I got the picture which has four red lines in it .It apprears that the middle part still unchanged.

I wonder whether i can access the unchanged pixels data.Please help me solve the problem.Thanks.

OK, here are my thoughts...

1) What is the size of the data structure you are accessing? Is it possible you are simply not 'flipping' enough data? The frame buffer pixel size is critical to the calculations.

2) Try halting the process which is writing to memory and simply keep calling the 'flip' routing. If the flip does not correctly flip, then this is where the issue is and we can focus on that alone.

3) Try using controlled data, e.g. write, say green pixels to the top part of the flip and blue to the bottom part. This will let you know if you are writing to the correct memory locations.

4) Limit the region you are modifying to say 1 line on the middle of the screen and write a fixed color. Again this will help you understand whether you are really changing the picture in the place you really are expecting.

A more efficient method may also be something lime the following...

unsigned char* temp;
unsigned char* upper;
unsigned char* lower;
unsigned int linestepsize;

linestepsize = inArgs->linelenth * sizeofpixel;

temp = malloc(linestepsize);
upper = &bufs[curBuf];
lower = &bufs[curBuf] + ((inArgs->linelenth) * (inArgs->height-1));

for(i=0;i<inArgs->height/2;i++)
{
    memcpy(temp, upper, linestepsize);
    memcpy(upper, lower, linestepsize);
    memcpy(lower, temp, linestepsize);
    upper = upper + linestepsize;
    lower = lower - linestepsize;
}

free(temp);

This is pseudo-code and I have not tried to compile it, but you should be able to understand my intent.

BR,

Steve