Displaying CIF

The display driver is expecting a frame of the size of the output resolution in YCbCr 4:2:2 format, in the case of a NTSC display this would be 720x480 (D1 resolution) and with 2 bytes per pixel it will be a contiguous array of 691,200 bytes, starting from the top left of the screen and going across for each line. The display will only support the resolution required by the display, in the case of a TV output for NTSC this is set at 720x480.

A CIF image of 352x288 would be 202,752 bytes and if you just copied that frame into the 720x480 display buffer it would not be aligned properly and would be squeezed into the top of the frame. This being said, if you wanted to copy the CIF image into the D1 display you would have to copy it line by line from the CIF, into each line of the D1 display. That is you copy 352 pixels, than offset to the next line (720-352) than copy the next 352 pixels than offset to the next line again and so on.

To put it in a simple ascii graphic you would copy data like (C for CIF capture, D for D1 display):

CCCCCDDDDDCCCCCDDDDDCCCCCDDDDDCCCCCDDDDDCCCCCDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD

So your output image will align properly like:

CCCCCDDDDD
CCCCCDDDDD
CCCCCDDDDD
CCCCCDDDDD
CCCCCDDDDD
DDDDDDDDDD
DDDDDDDDDD
DDDDDDDDDD

As opposed to squishing into the top of the screen like:

CCCCCCCCCC
CCCCCCCCCC
CCCCCDDDDD
DDDDDDDDDD
DDDDDDDDDD
DDDDDDDDDD
DDDDDDDDDD
DDDDDDDDDD

If you just copied it into the display buffer directly like:

CCCCCCCCCCCCCCCCCCCCCCCCCDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD

I am not sure what DaVinci platform you are using but one thing to keep in mind when resizing is the input/output pixel clock.  You see, more often than not, you are using the same pixel clock (aka video clock) for video input and video output.  Therefore, if you are using a different capture and display resolution, your refresh rates will have to be managed accordingly or you will get weird results ( pixel clock = resolution x refresh rate).  For this reason, our demos assume the same resolution for input and output so if you want PAL input and CIF output you could try

./encodedecode -y 2 -v mpeg4 -r 352x288

the '-y 2' option tells software it is PAL input, and -r option tells it the output size.  If different, it uses HW resizer to resize image and outputs PAL video (same as input) with CIF picture in center.  It still uses same input and output size (same pixel clock), but embeds output size specified in -r option (must be smaller or equal to input size) in center of output frame.

Hi Bernie and Juan ,

Thanks for the information..

@Juan,

I am using DM6437EVM  and i didnt understand how to specify this command ./encodedecode -y 2 -v mepeg4 -r 352x288 in my application. Could yopu please elaborate the same.

Thank you,

Thupakula.

Apologies Thupakula, my example command line only applies to some of our ARM-based products.  I did not realize you were using DM6437 (DSP only part).  I am not too familiar with the software for DM6437 platfom, but the pixel clock challenges still apply; maybe someone more familiar with the software will chime in and offer advice.

Hi Bernie,

I tried to copy as you told ,like this.

  Ptr1 = dispalyframe->frame.frameBufferPtr;
        Ptr2 = outputbuf;  //is containg actual frame.

 if(IOM_COMPLETED == FVID_allocBuffer(hGioVpbeVid0,&dispalyframe))
     {
     index1 = 0;
     count  = 0;
     for(index2=0; index2<((Outwidth* Outheight* 2));index2++)
     {
         *(Ptr1+index1) = *(Ptr2+index2);
         
         count++;
         if(count == 352)           
          {     
            index1+=368 ;
              count=0;                
              }
              index1++;
     }

        
      if(IOM_COMPLETED != FVID_queue(hGioVpbeVid0,dispalyframe))
        {
                printf("VPSS  :Video 0 Queuing.......FAILED \r\n");
        }

but nothing is diplayed..  Is this the right way to do ? (sorry for making sill doubts)

Thank you,

Thupakula.

could anyone respond for the above as it is urgent for me .

Thank you,

Thupakula.

There are a lot of pointers to manage in here and you have to keep everything aligned, I took the accessing pixels in a frame example and added a function in it to draw a box of another frame buffer (or any YCbCr 4:2:2 data) on the screen, something like:

Some Code said:

//draw a box
void process_imagebox( void* currentFrame,  int yRows, int xPixels, int xoffset, int yoffset, int xsize, int ysize, void* boxValues)
{
 int xx = 0;
 int yy = 0;

    if(xoffset+xsize*2 > xPixels){
  printf("ERROR: invalid arguments to process_imagebox, out of frame in x direction");
  return;
  }
 if(yoffset+ysize > yRows){
  printf("ERROR: invalid arguments to process_imagebox, out of frame in y direction");
  return;
  }

    for( yy = 0; yy < yRows; yy+=1 )//operate on all rows
     { 
      for( xx = 0; xx < xPixels; xx+=1 )//operate on all columns
        {
           if(xx > xoffset && xx < xoffset+xsize && yy > yoffset && yy < yoffset+ysize)
           *( ( (unsigned short*)currentFrame ) + ((yy*xPixels)+xx) ) = *( ( (unsigned short*)boxValues ) + (((yy-yoffset)*xsize)+(xx-xoffset)) ); //draw in the box
        }
     }
} // End process_imagebox()

 

If you insert this into the example along with some code to generate a buffer of data (in this case incrementing test data):

Some Code said:

  boxBuffPtr = malloc(20000);
  for( xx = 0; xx < 20000; xx+=1 )
   *( ( (unsigned char*)boxBuffPtr ) +xx) = xx;

And than call the function in your processing loop like:

Some Code said:

  while (!done && status == 0) {
    FVID_exchange(hGioVpfeCcdc, &frameBuffPtr);
    process_imagebox( (void*)(frameBuffPtr->frame.frameBufferPtr), 480, 720, 200, 200, 100, 100, (void*)boxBuffPtr); //draw a 100x100 box 200x200 from the top left corner
    BCACHE_wbInv((void*)(frameBuffPtr->frame.frameBufferPtr), 480*720*2, 1);
    FVID_exchange(hGioVpbeVid0, &frameBuffPtr);
    }

Than you should see the box drawn on the screen, this same sort of code could be used to draw in your particular frame on the display, you would just need to adjust the sizes. Of course I have not tested it on your particular setup, so you may have to make adjustments, but hopefully this can be of some help.

Just an update, there should not be a *2 in the xoffset portion of the line that actually copies in the image data as edited in the post above.