• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 98 subscribers
  • Views 475 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.

why turn off vrfb when compile video capture sample

Huai Hellen
Expert 1030 points
Other Parts Discussed in Thread: OMAP3530

Hi, all

on evm2(omap3530 rev.g) borad, to make video capture program work corretly, we must set bsp_novrfb=1

My question is : why this? It is said the current vrfb driver is conflict with micro current code, if this is true,

Does TI have plan to reslove the problem?

  • 0
    TI__Prodigy 300 points

    Hellen,

    It appears that the capture driver does not handle the stride required by the VRFB hardware. This is a known issue and documented as follows in the readme.txt available with the 6.14 BSP:

    - If the VRFB is enabled, the video capture driver (camera_mdc) and the
    sample video capture application will malfunction.

    I am investigating this issue and will post an  update on this forum if a fix is found.

    As a workaround, you could force the renderer to be in GDI mode by doing something like this:

    g_DShowCaptureGraph.SetVideoRenderMode(AM_VIDEO_RENDERER_MODE_GDI);

     

    Regards,

    Chander

  • 0 in reply to craja
    TI__Prodigy 300 points

    Hellen,

    Currently, preview mode is turned off in the capture driver and is handled by the capture graph builder.  I enabled preview mode in the capture driver and  my observation was that the VRFB stride information is not passed by the renderer to the capture driver. It should normally be passed in the biWidth field of the BITMAPINFOHEADER structure as is described here:

    http://msdn.microsoft.com/en-us/library/dd318229%28v=VS.85%29.aspx

    This leads me to believe that the buffer passed to the capture driver is not the DirectDraw frame buffer but another buffer allocated by the Microsoft supplied default renderer which then performs another copy to the actual frame buffer without taking the stride into account which would explain why preview is not working with VRFB enabled.

    One solution may be to write a custom renderer that handles the stride correctly. Of course, the simplest solution is to handle preview in GDI mode until Microsoft fixes the renderer. Microsoft has fixed stride issues in its decoders for Chelan and it may have fixed the default renderer in Chelan as well.

     

    Regards,

    Chander