not getting correct frame

i couldnt paste that so please find the below link

http://e2e.ti.com/cfs-file.ashx/__key/CommunityServer.Discussions.Components.Files/33/0028.Dok1.doc

I do not see anything wrong with the source code; the way I see it, the problem could be in the pointer being used or the how seqView tool is using the data (YUYV vs UYVY); in order to narrow down the problem I would fill buffer with a know YCbCr 4:22 pixel value (e.g 0xA28EA22C for yellow),then you can

1) inspect out.yuv file for correct values (will tell you if write C code is working as expected)

2) open file with SeqView tool and see if you can view the color expected (yellow), which will verify the tool is working as expected.

if you do not find any problems with the two steps above, than the problem is likely that you are using an incorrect buffer pointer

framepointer= (int *)0xA28EA22C;

fwrite(framepointer,framesize,1,out);

If i do like this(am I doing write ? ), iam getting many colors as attached below

http://e2e.ti.com/cfs-file.ashx/__key/CommunityServer.Discussions.Components.Files/33/3683.Dok2.doc

so the code snippet above is just setting framepointer to address to 0xA28EA22C (which probrably explains the drastic change in video data, who knows what is stored at this pointer)  rather than setting this value in the buffer, what I had in mind was something like a for loop to set the entire buffer (what video resolution are you using by the way?) to yellow, so it can easily be inspected via binary editor to make sure write worked as well..

I am using 720 * 576 resolution.. To be honest i am confused with the buffer value i mean  how to set this value to the buffer. If u can , could you please provide me the code for this ?

so I assume you are using one of our DaVinci processors (which paltform?), if so an integer is defined as a 32-bit value.  Due to the typecasting you are using, I assume you have frame pointer as an pinter to integers (e.g. int * framebuffer) since you did not explicitely post that part of the code.  If so,  what I had in mind was

    size_in_bytes = 720 * 576 * 2;

    size_in_integers = size_in_bytes / 4;       //note each int is 32-bits or 4 bytes

    for (i=0; i < size_in_integers ; i++)

       framebuffer [i] = 0xA28EA22C;        //assumption of frambuffer being declared as 'int *' is important here.

Granted, this can be coded many other ways, this is just one way...

  /* prime up the video capture channel */
  if (status == 0) {
    FVID_queue(hGioVpfeCcdc, frameBuffTable[0]);
    FVID_queue(hGioVpfeCcdc, frameBuffTable[1]);
    FVID_queue(hGioVpfeCcdc, frameBuffTable[2]);
  }

   

  /* prime up the video display channel */
 /* if (status == 0) {
    FVID_queue(hGioVpbeVid0, frameBuffTable[3]);
    FVID_queue(hGioVpbeVid0, frameBuffTable[4]);
    FVID_queue(hGioVpbeVid0, frameBuffTable[5]);
  } */

  /* grab first buffer from input queue */
  if (status == 0)
   {
    FVID_dequeue(hGioVpfeCcdc, &frameBuffPtr);

    out = fopen(filename,"wr");
    if ( out == NULL)
    {
    printf("unable to create output file");
    }

    framepointer =(int *)(frameBuffPtr->frame.frameBufferPtr);
    size_in_bytes = 720 * 576 * 2;

    size_in_integers = size_in_bytes / 4;       //note each int is 32-bits or 4 bytes

    for (xx=0; xx < size_in_integers ; xx++)
     {
       framepointer[xx] = 0xA28EA22C;
     
     }

      fwrite(framepointer,framesize,1,out);

I declared framepointer as  int * .

but still i dint get the yellow output from my seqView..

Is there any to find  whether SeqView is reading correctly or not ?

I am using DM6437EVM.

and i dont understand what is mean by the cache coherency ? does this has any effect in this case?

you may be on to something here.  unfortunately, I am not very familiar with DSP, so I will let one of our experts comment on this. 

In the mean time, can you open the out.yuv file with a binary editor and verify that hex values for the color yellow was written by the program throughout the entire file?  Also, you can check the size of the file to make sure it makes sense, file size = 720x576x2?  If the file looks ok, you may want to use yuv viewer from elecard as it gives you the option to select the yuv format (uyuv, vyuy...) and this may make a difference.

one more notice..

r u sure that the value 0xA28EA22C is yellow ?

because i tried to assign the buffer only  0xA2 then my output is all green.

This is a value I used a while back while working on a project; it assumes Y= 0xA2 (or 162) , Cr=0x8E (or 142), and Cb=0x2C (or 44).  If you plug-in these decimal values into http://www.dvd-replica.com/DVD/colorrgb2.php, you should see some shade of yellow.  Of course you can try other colors as well.

FYI, writting A2 to all bytes (Y, Cb and Cr) should yield a pinkish color.

Here the frame output is from the TVP5146 decoder. According to my understanding the frame should in YUV422(cbYcrY..)format. and it is stored in interleaved pattern and the mode is interlaced. How Does YUV elecard  reads this data?

so you have complete control of the frame inside the user application; therefore the application can piece together the odd and even fields of an interlaced stream into a complete video frame.  Therefore, so long as you know the pixel format (CbYCrY) and the resolution (720x576) you can pass this information into elecard YUV viewer and it should be able to display to file fine.

In our previous test scenerio, you have complete control of the video frame and can write all yellow pixels (or any other color) into the frame so you know what to expect on the YUV viewer.  At this point, we are not even dealing with piecing together interlaced fields..

here i have a basic doubt about fwrite  function.

can i write the content of  frame(by using below syntax) directly in the out put file ?

fwrite(frameBuffPtr->frame.frameBufferPtr,framesize,1,out);

Hi Juan,

Now iam getting the correct frame but there are some pinkish n greenish colors are coming dont know why ?

please find the outbelow n can u suggest something abt this?

http://e2e.ti.com/cfs-file.ashx/__key/CommunityServer.Discussions.Components.Files/33/6237.Dok2.doc

I am really doing so much hard work to get this but couldnt get.

Doe Elecard read YUV422 interleaved format?

I do not see any options for interleaved, so I would assume you need to make sure your frame is progressive; otherwise you may need to adjust the size of your frame to match the size of your field, but you should still be able to see a useful image

Thank u Juan..

But  I noticed an options  in ELecard  IYUV , 12YU,16YU. can u please tel me what are these options ?

So you want me to convert this frame into progressive ?

And also could you please suggest me something abt the pinkish and greenish colors in the frame i wrote into a file. please find the frame here in the below link

http://e2e.ti.com/cfs-file.ashx/__key/CommunityServer.Discussions.Components.Files/33/6237.Dok2.doc

Thupakula said:

And also could you please suggest me something abt the pinkish and greenish colors in the frame i wrote into a file. please find the frame here in the below link

http://e2e.ti.com/cfs-file.ashx/__key/CommunityServer.Discussions.Components.Files/33/6237.Dok2.doc

Those pink and green lines like that make it look like you would have noise on your sync lines somehow, or perhaps more specifically that your sync signals are getting just slightly misaligned with the data to the point that the data is one byte off. That sort of pink and green color output is what it looks like when you have your luma (Y) and chroma (Cb/Cr) swapped (i.e. it is actually getting YCbYCrYCbYCr... but it thinks it is getting CbYCrYCbYCrY...), and since it is happening intermittently down the image on seemingly random horizontal lines it looks like a sync issue. Is there any other hardware hooked up to your DM6437 EVM, or are you actually just reading image data from the on board TVP5146 video encoder?

Hi Bernie,

I am Just reading the data from the TVP5146 decoder by using fwrite

fwrite(frameBuffPtr->frame.frameBufferPtr,framesize,1,out);

and trying to open with Elecard.

could you please explain me what is the sync issue in detail?

And also

When I observed the frame pointer in quickwtch , I notice that it is not able to read some memory locations saying  "Trouble reading memory at 0x08080808 on Page 0"  like that. Does this  cause any problem for fwrite to write the values in to the file ? ( I guess it s the problem with memory mapping am i correct? ). If so,  how can i resolve this?

Please help me in this as iam working on this since long time..

Thank you,

Thupakula

I am not too familiar with quickwtch, but I suspect this is a user space application.  In Linux, user space apps access memory via virtual pointers (cannot access physical memory directly); so perhaps this is leading to the unexpected values.

Thupakula said:

I am Just reading the data from the TVP5146 decoder by using fwrite

fwrite(frameBuffPtr->frame.frameBufferPtr,framesize,1,out);

and trying to open with Elecard.

could you please explain me what is the sync issue in detail?

The sync issue is a hardware issue, I used to see the same situation when I had a relatively long ribbon cable between two boards that was passing a digital video signal from one to the other, depending on how the cable was positioned the output could be all correct colors, all green/pink, or some mixture with some lines ending up green/pink and some ending up correct colors. Since green/pink is what you get when you have luma and chroma swapping my conclusion on the phenomenon I was seeing was that the data capture was starting one clock off from what it was supposed to, so that the YCYCYC was being read as CYCYCY, which would mean that the external horizontal sync was not maintaining signal integrity across the cable. Are the horizontal green/pink lines in a constant position or are they seemingly random on the images you are getting out?

However in the case you have here if you are just reading data from the TVP5146 I do not see how you could end up with such a phenomenon, since the TVP5146 is known to be good in hardware on the DM6437 EVM, I only saw this phenomenon with a daughtercard, do you have any hardware modifications on your DM6437 EVM?

Thupakula said:

When I observed the frame pointer in quickwtch , I notice that it is not able to read some memory locations saying  "Trouble reading memory at 0x08080808 on Page 0"  like that. Does this  cause any problem for fwrite to write the values in to the file ? ( I guess it s the problem with memory mapping am i correct? ). If so,  how can i resolve this?

This does certainly sound like a memory mapping problem, the address 0x08080808 is not valid memory, but a reserved space in the DM6437, so it is not suprising that it cannot be read properly. If this is happening it would mean either you are not really looking at the frame pointer, or your frame pointer is otherwise corrupted, I suspect the former as if your frame pointer was really this broken I would expect no image output at all since it is unlikely you could write to 0x08080808. You may want to look at the code that is allocating the frame buffers and ensure that they are being allocated properly, the frame pointers should all be in 0x80000000+ for placement in external DDR.

Hi Bernie,

Here the framepointer is in the DDR2.. but some values of y, u , v are not readable. For more clarification iam attaching the screenshot  , in which u can find this in quickwatch.

Thank u .

http://e2e.ti.com/cfs-file.ashx/__key/CommunityServer.Discussions.Components.Files/33/8713.Dok1.doc

Hi Bernie,

can you please comment on the below frames that we got with fwrite in binary mode ( "wb")and actual mode ("w") ?

http://e2e.ti.com/cfs-file.ashx/__key/CommunityServer.Discussions.Components.Files/33/3377.Dok3.doc

Thank u in advance,

Thupakula.

Thupakula said:

can you please comment on the below frames that we got with fwrite in binary mode ( "wb")and actual mode ("w") ?

The binary mode certainly looks better, though greyscale, I think you have found the problem as to why you were getting pink/green horizontal lines on the image with the wb versus w modes of fwrite. If you try to output the image as an ascii text file as implied by the default w mode the formatting may not be maintained properly since everything is being interpreted as characters and you end up with end of line characters inserted, which would cause offsets such that the image viewer reading the file would end up getting misaligned between the luma and chroma. Essentially you have reproduced the sync issue I had seen on noisy hardware by having end of line characters inadvertently inserted in the image output by fwrite.

So cant we read the color frame? (I mean how to read the color frame?)

Hi Bernie and Juan,

I got the outframe as expected.

Thank you very much for all your support and help.

I am glad to hear it, what did you have to do to get the color frame? Since you had the green and pink going there the color data was certainly being expected.

Hi Bernie,

I didnt change anything. But with the file write mode as binay only i got the clear frame.

Today I tried to resize it to   352 * 288 with Resizer. But After this again I am not getting the frame properly(all pinkish).  please find the code below.

Please find both the frames below before and after the resizing .

http://e2e.ti.com/cfs-file.ashx/__key/CommunityServer.Discussions.Components.Files/33/4532.Dok1.doc

Thanks,

Thupakula.

Please find my source code here ( for above)..

        /*  Resizer */
   printf("GIO_create: Start\n");
    Resizer = GIO_create("/RESIZER",IOM_INOUT,NULL,(void *)&SegId,&gioAttrs);
   printf("GIO_create: End\n");
   if(Resizer==NULL)
   {
       printf("Resizer NOT created\n");
    exit(0);
    }
    if (NULL == ResizerBuf1)
    {
        /* Memory allocation for  output buffers */

        ResizerBuf1 =(Char *)MEM_alloc(0,Outwidth*Outheight*(2u),(128u));
        if (ResizerBuf1  == NULL)
        {
            statusOP = -1;
        }


    }
    if (-1 != statusOP)
    {

   GIO_control(Resizer,PSP_RSZ_IOCTL_SET_PARAMS,&controlparams);  //  setting resizer chnnael parameters
   printf("GIO_control: Setting Parameters: End\n");

   Buf1.inBuf = frameBuffPtr->frame.frameBufferPtr ;  //input buffer starting address   
   Buf1.outBuf = ResizerBuf1;   //output buffer starting address
   Buf1.inBufSize = Inwidth* Inheight* 2; // input buffer size
   Buf1.outBufSize = Outwidth* Outheight*2 ; //  output buffer size

   statusOP = GIO_control(Resizer,PSP_RSZ_IOCTL_RESIZE,&Buf1) ; // resizing
   if (0 > statusOP)
        {
            printf(" IOCTL failed \n");

        }

   printf("GIO_control: Actual Resizing: End\n");

  out_resize = fopen("..\\out_resize.yuv","wb");
    if ( out_resize == NULL)
    {
    printf("unable to create output file");
    }

          fwrite(ResizerBuf1,Buf1.outBufSize,1,out_resize);

  GIO_delete(Resizer);

 }

Thupakula said:

Please find both the frames below before and after the resizing .

http://e2e.ti.com/cfs-file.ashx/__key/CommunityServer.Discussions.Components.Files/33/4532.Dok1.doc

often, when you get odd colors like this, it is likely that one or more of the chroma components is missing (perhaps Cb= chrom blue in this case) or Cb and Cr components are swapped.  I am wondering if the resizer is messing around with the pixel order... a simple test consisting of writting a single pixel value throughout the entire buffer (such the resized frame should also have that same exact value) should prove if this is a resizer issue or not.

I tried to give only single value like this

for (i = 0 ; i<(Inwidth*Inheight*(2u));i++)
 {
   *input = 0x00 ;
   input++;
 }

   Buf1.inBuf = input ;  //input buffer starting address   
   Buf1.outBuf = ResizerBuf1;   //output buffer starting address
   Buf1.inBufSize = Inwidth* Inheight* 2; // input buffer size
   Buf1.outBufSize = Outwidth* Outheight*2 ; //  output buffer size

then iam getting only pink color for different values of input buffer as shown below.

http://e2e.ti.com/cfs-file.ashx/__key/CommunityServer.Discussions.Components.Files/33/7888.Dok4.doc

can you open the file using a binary editor and examine the pixel value to see how it differs from what you wrote.  Is the pixel data out of order (Cb and Cr swapped, or missing...)?

It is putting  ff and 80 ( I kept 2C).

http://e2e.ti.com/cfs-file.ashx/__key/CommunityServer.Discussions.Components.Files/33/8244.Dok4.doc

totally not what I would expect; you appear to be writing all zero's (color green) but are getting pixels with 0xff and 0x80 values; to get the pinkish colors, it would appear your Cb and Cr components are set to 0xff, and your luma (y-component) is set to 0x80.  though I would not expect resizer to change the colors so dratically.  Can you perhaps store buffer before and after resizing to separate files to confirm values.

I am not quite sure what you meant by "I kept 2C"?

Hi Juan,

As expected I am getting all values in the frame as 00 in both before and after the resize .  But with the actual frame,  most of the chroma values are setting to ff. Dont know why?

Does this mean that when you read the file via binary editor you now see all 0s as opposed to 0xff and 0x80?  If not, how are you verfying that all zeros are present?

Hi Juan,

Yes . I used  editor. Bothe the files are contaoning 0s only. I verified by opening with FRhed(hex editor) and the frames(both before and after) are also in green color when opened with Elecard. But when I am doing the same resizing for the actual frame pointer( frame buffer pointer in my application) , MOst of the chroma values are setting to ff. What could we expect the reason for this?

The pink may indicate another byte offset, the fact that it appears to resemble the output you want is a good thing though, looking at the bytes like Juan suggests is a good idea to try to figure out what it should be, in particular comparing the bytes of a good image to the pink image.

FYI, instead of posting all of your pictures into .doc files you attach, it would probably be easier (to post and to read) if you use the insert media button  in the post editor, this way the image just shows up in the post and you dont have to bother with uploading .doc files.  

That is weird; based on your tests it appears that

1) when your input buffer is all zeros, your resized output buffers is all zeros as well as expected.  Granted, writting all zeros for Y and Cb/Cr components is probrably not the best choice since it does not let you distinguish between to detect any potential swapping of pixel order.  It is also a mystery why you did not get all zeros in the output buffer (but rathee 0x80 and 0xFF ) the first time you tried this.  Does removing the 'write to a file' prior to resizing affect this (it should not)?

2) when your input buffer is a valid image, your resized output buffer appears to have 0xFFs for all Cr/Cr components.  One potential thing we can explore is filling output buffer with a know value (say 0x55) prior to resizing; if resizer returns back Cb/Cr values of 0x55 as opposed to 0xFF, than it probrably means the resizer is skipping some bytes when it writes output (could be a conflict in input vs output pixel format hardware configuration).  If you see 0xFFs for chroma components instead of 0x55s, then we will need to investigate what may be causing this a little further. 

Here I was using the downscale example in my application. So I copied the same filter coefficients in my application but iam trying to downsize from 720*576 to 352*288.  In this case iam getting most of the chroma values are setting to '0xff' .  I also tried to downsize from 720 * 576 to 360 *288 (exactly half of input frame). then i am geting the frame correctly.

I guess theere is a  problem  with the filter coefficients . In the userduide it was said that  in the range iof  1/2x to 4X we can use 4 tap filter coefficients and user has to fine tune these coeffiecients for different images.

Can you pls suggest me how to tune these coefficients for tuning the image of 352*288 resolution?

Thank u,

The following App Note describes how to calculate the coefficients using a utlity (which I believe is included with the App Note).  The App Note also describes some alignments that must be met when defining input and output image sizes.

http://focus.ti.com/general/docs/litabsmultiplefilelist.tsp?literatureNumber=spraai7b

Thupakula ,

did you have an additional question?  Your last post just has a blank image but no text and I was not sure what you wanted us to do with this...

Hi  Juan,

Sorry for the last empty post.I tried to paste an image but couldnt..

I am strucked in resizing.. After i run my application ,I halted the program n did reset the CPU. And I loaded the program again to execute..

When I am doing such that.. i am getting the previous frame ast which i stopped the program execution before. I think this is bcos of the drivers are not cleared.

I have a basic doubt i.e do we need to flush the drivers explicitely or as soon as we reset the program does the drivers are flushed?

Thank you,

Thupakula.

Thupakula said:

I have a basic doubt i.e do we need to flush the drivers explicitely or as soon as we reset the program does the drivers are flushed?

The drivers should flush themselves as your program starts running, since the capture driver will start overwriting the buffers with new image data, and your application will be overwriting the buffers in the display, so in general you should not have fo flush the drivers as long as you don't mind seeing the last frame from before at first. Essentially the drivers do not flush themselves at start, i.e. they do not clear out the memory that they allocate their buffers into, so if what they allocate happens to be the same as a prior run, and happens to still contain prior images, you will see them at first until they are written over as the driver cycles through frames.