• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 100 subscribers
  • Views 429 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

DM8168 resolution problem!

Brown John
Prodigy 45 points

Hi~ I am using DVR RDK 04.00.00.03, and I want to test the SW_OSD link. Here is my link chain:

The input video resolution is 720*576. And I want to change the frame in the dsp side. As a test, I set half of my Y frame buffer to be 0 in the DSP_ALG_OSD link:
        
myAddr=(UInt8 *)pSwOsdObj->videoWindowAddr;
UInt32 pitch=pSwOsdObj->videoWindowPrm.lineOffset;

for(ii=0;ii<576;ii++)
  {
    for(jj=0;jj<360;jj++)
    {
     myAddr[ii*pitch + jj] = 0;
    }
  }

but it turns out to be like this:

Obvioursly the black area does not take half of the screen, and there is a non-black strip on the foot. It seems like that the resolution of the video(720*576) has been changed somewhere. Why does this happen?

  • 0
    TI__Guru 59700 points

    The image you have attached is not visible. Pls reattach

    Check the actual input resolution in OSD link by checking the value in System_FrameInfo. Depending on the usecase and channel you choose capture may be scaled or not.

    Check the input format (Whether it is YUV420SP or YUV422I)

     

  • 0
    Intellectual 830 points

    That's because M3video and C6xdsp used the same image buffer. M3Video starts enconding the H264 while C6xdsp starting its work. 

  • 0 in reply to Badri Narayanan
    Prodigy 45 points

    I do not use the capture link nor the scale link, here is my link chain:

    The screen out put looks like:

    I also checked System_FrameInfo->captureRtParams.captureOutWidth and captureOutHeight, they were both zero. where dose the resolution change? Confused...

  • 0 in reply to Brown John
    TI__Guru 59700 points

    Decoder output is padded as it is also used as H264 decoder reference buffer. You should use startX,startY to determine correct start of video .

    Add Vps_printf in /dvr_rdk/mcfw/src_bios6/links_c6xdsp/alg_link/swosd/osdLink_alg.c

    AlgLink_OsdalgProcessFrame

        if(pFrameInfo->rtChInfoUpdate)
        {
            /* Need to comment this as we dont update this when we update frameInfo in IPCFrameIn*/
    //        pSwOsdObj->videoWindowPrm.format = pFrameInfo->rtChInfo.dataFormat;
            pSwOsdObj->videoWindowPrm.startX = pFrameInfo->rtChInfo.startX;
            pSwOsdObj->videoWindowPrm.startY = pFrameInfo->rtChInfo.startY;
            pSwOsdObj->videoWindowPrm.width  = pFrameInfo->rtChInfo.width;
            pSwOsdObj->videoWindowPrm.height = pFrameInfo->rtChInfo.height;
            pSwOsdObj->videoWindowPrm.lineOffset = pFrameInfo->rtChInfo.pitch[0];
        }

    to print startx,starty,width and height

  • 0 in reply to Badri Narayanan
    Prodigy 45 points

    Thanks! problem solved. Just add startX and startY to my address:

    myAddr=(UInt8 *)pSwOsdObj->videoWindowAddr + pSwOsdObj->videoWindowPrm.startX + pitch*pSwOsdObj->videoWindowPrm.startY;