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 OMX - 2 displays (SD and HD1)

Hi all,

I am trying to use EZSDK OMX (version 5:05:01) on an DM816x module to capture and display out second HD port (DV02) and SD port.

Using OMX.TI.VPSSM3.VFCC for capture, OMX.TI.VPSSM3.VFPC.DEIMDUALOUT for DEI, OMX.TI.VPSSM3.VFDC for both displays (2 instances) and OMX.TI.VPSSM3.CTRL.DC for control (2 instances).

SD is PAL and DV02 is an LCD 800x600 display.

I have had DV02 working with the second DEI port going to an encoder (similar to example decode_display).
I have also had SD working by shifting encoder to first port of DEI and putting SD on second port. So I have had both displays working independently, just not at the same time.


The problem I am having is that when I try to support both DV02 (port 0 of DEI) and SD (port 1 of DEI) and try to take them to the execute state, the DV02 gives an OMX bad parameter error.
I have checked and double checked everything and simply can't see any parameter errors I have made. One interesting observation is that it is only the DV02 that gives the bad parameter. If I put the SD into execute state first then it is successful.


So I have a few basic questions:
1) Should I expect both HD and SD to be possible at the same time via OMX (documentation says it should be possible)
2) If yes, then I assume I need 2 instances of a VFDC and 2 instances of an associated controller i.e. 2 lots of below, 2nd would have a different set of AppData
/* Create the display component */
err = OMX_GetHandle (&pAppData->pDisHandle, "OMX.TI.VPSSM3.VFDC", pAppData->disILComp, &pAppData->pCb);
if (err != OMX_ErrorNone)
{
ERROR("failed to get handle\n");
return err;
}

/* getting display controller component handle */
err = OMX_GetHandle (&pAppData->pctrlHandle, "OMX.TI.VPSSM3.CTRL.DC", pAppData->disILComp, &pAppData->pCb);
if (err != OMX_ErrorNone)
{
ERROR("failed to get handle\n");
return err;
}

3) Is there any example code of using two displays or has someone else achieved this - I can't find any examples around.

Kind regards

Shane Harrison

  • Hello,

    In EZSDK we does not have such example.

    You could try to gstreamer pipeline to test it.

    With gstreamer this should work: for displaying video on HDMI and LCD.
    st-launch filesrc location=/usr/share/ti/data/videos/dm816x_1080p_demo.264 ! 'video/x-h264' ! h264parse access-unit=true ! omx_h264dec ! omx_scaler ! omx_ctrl display-mode=OMX_DC_MODE_1080P_60 ! gstperf ! omx_videosink sync=false filesrc location=/usr/share/ti/data/videos/dm816x_1080p_demo.264 ! 'video/x-h264' ! h264parse access-unit=true ! omx_h264dec ! omx_scaler! omx_ctrl display-mode=OMX_DC_MODE_1080P_60 display-device=LCD ! 'video/x-raw-yuv,width=(int)800,height=(int)480' ! gstperf ! omx_videosink sync=false display-device=LCD

    One note the latest ezsdk version is 5.05.02. I would recommend you the latest version.

    BR
    Margarita
  • Thanks Margarita.

    My error, I am actually using 5:05:02 after all.

    Using gstreamer to test pipelines is a good idea in general. However in my case there are two many differences in my desired pipeline in terms of combining both fields captured into one buffer for it to be a real test. I also though LCD was HD1 not the SD VENC?

    I have made some progress and proved that cascading the two DEI's should work and it appears both HD1 and SD is possible. I will explain where I have got to.

    Pipeline is:
    CAPTURE --> DEI A --> DEI B --> VFDC (HD1)
    | | --> VFDC (SD)
    |
    | ---- ---> ENCODER --> file

    CAPTURE - setup to have both fields in the one buffer, interleaved - 720x576. This is so mpeg2 encoder can produce an encoded interlaced output
    DEI A - Set in bypass mode - hence can't do scaling from what I understand so both outputs 720x576
    DEI B - Bypass or not bypass doesn't seem to make a difference. Port 0 - 720 x 480, Port 1 - 720x576. I thought if not in bypass then it should be able to scale to 720x480 (or 800 x 480)
    HD1 - set to 720x480
    SD - set to 720 x 576

    So with that setup I get BAD PARAMETER OMX error on trying to put HD1 into execute mode. If I change HD1 to 720 x 576 then OMX pipeline runs (obviously screen is a mess because resolution wrong but it all appears to work). So it looks like forcing a scaling on the port 0 of the DEI B to 720 x 480 is causing me issues. I inserted a Noise Filter component followed by a Scalar between DEI B and HD1 but got the same error (I was thinking maybe DEI B can't scale for some reason).

    So questions I have are:
    1) The only thing I have to do to disable bypass on the DEI B is to unset the alg.bypass parameter - correct ?
    2) If I unset the disable bypass then scaling the port 0 output independent of port 1 is possible - correct ?
    3) To set up scaling do I simply set the nFrameWidth and nFrameHeight on the output port along with the Frm0Width and Frm0Height - correct?

    Any help or thoughts really appreciated. I feel I am very close but missing some piece of vital information.

    Kind regards
    Shane
  • Hello,


    Please check the default decode_display demo in EZSDK. You could see that noise filter element is add for SD display.

    You could look in it for example.

    BR
    Margarita

  • Thanks Margarita.  I had already looked at the code in decode_display when I inserted an NF component into the pipeline.  NF was used for conversion from 422 to 420 and a scalar followed that.  I copied that idea.  As I said though, it didn't change my error that I was seeing.

    Do you have any answers for the three questions I posed in my last post?    

    Also I am wondering what constraints there are on scaling i.e. can I scale from 720x576 to 800x480 - should that be possible?  

    Kind regards

    Shane

  • Hello,

    What is dm8168 revision?

    If it is 1.1 please check OMX release notes:
    "SD display width has to be 720 for DM8168 PG1.1"


    Are you able to scale 720x576 to 720xYY?


    You could run ./loggerSMDump.out 0x9e400000 0x100000 all for more debug prints.

    BR
    Margarita

  • My problem is not SD but DV02 (LCD screen).  SD is fine at 720x576 and working fine.  DV02 at 800x480 is my problem.

    I ran loggerSMDump.out and it indicated I was trying to use interlaced input into the DV02 VENC when it was expecting progressive.  Not sure how it determined that input was interlaced.  However changing the timings under sysfs to expect interlaced input removed this issue (I use a custom display OMX setup).

    So OMX now runs and examing the buffers into the DV02 they look OK but no picture.  I think it is scaling OK to 720 x 480 but not sure yet.

    How does the VFDC know that the input is interlaced (fields interleaved in one buffer in my case) ?  I have played around with the fieldsMergeInfo parameter but that has had no impact and anyway that isn't about progressive vs interlaced, rather once interlaced what is the buffer format.

    Kind regards

    Shane

  • Hi Margarita,

    My test scenario is now a VFCC component (capture interlaced source) feeding a DEI-H component in bypass mode.  The two outputs from the DEI got to DV02 (800x480) and SD (PAL - 720x576i)

    VFCC is delivering both fields in one buffer, interleaved, so called fieldMerged mode.

    As soon as I add a VFDC for SD to the pipeline the video pipelines seem to be understood to be interlaced.  This has forced me to set my DV02 VENC into expecting interlaced input.

    SD is working fine.  DV02 shows nothing

    I have captured the buffer going to the VFDC (DV02) OMX component and it is scaled correctly and is in 422 YUV mode.  The problem seems to be that the VFDC can't deal with fieldsMerged or something else about the format of the buffer I am presenting to it.

    Cheers

    Shane

  • I now currently have an OMX executable that connects the Dual DEI outputs to DV02 and SD respectively. Enabling one or the other, everything works fine. If however I try to enable both then VFDC connected to DV02 won't go into execute mode. I think the issue is that as soon as the SD is used then all OMX pipelines are interlaced and the VFDC for the DV02 can't cope with that. The buffer format is "FiledsMerged" so actually each buffer has a full frame but I think that is causing problems.

    Interestingly, I compiled with only the SD active and ran the executable. I then had a separate V4L2 application that writes a static buffer to the DV02 via V4L2 interface. This V4L2 exe will not run (dequeuing fails) if the OMX with active SD is running. I suspect it is related.

    Any thoughts anyone?
  • Hello,

    Shane Harrison said:
    Interestingly, I compiled with only the SD active and ran the executable. I then had a separate V4L2 application that writes a static buffer to the DV02 via V4L2 interface. This V4L2 exe will not run (dequeuing fails) if the OMX with active SD is running. I suspect it is related.

    If I understand you right, you are  trying to run one app with v4l2 and one OMX app at the same time,right?

    If yes, what error you observe?

    Have you tried with gstreamer ?

    BR
    Margarita