Ezsdk-writeback driver support hdvpss(DM8168)

Hello,

You could try to search for VPS_CAPT_INST_VIP0_HDCOMP in hdvpss package. It seems that this is the port used for capture writeback.
HDVPSS also has example for capturewriteback and there is a chain-link example also in chains_writeBackCaptureTvp5158.c

Search for CaptureCompWb_main.c.

BR
Margarita

Hi Margarita,
Thanks,I have gone through those examples you mentioned.
I am getting some portion of the full frame through writeback capture(When I am playing the graphics SDK examples) through VIP0_HDCOMP.

I couldn't able to run both VIP_PORT0 capture and the VIP0_HDCOMP instance on the capture driver. I nee to try the write-back of my camera data instead of the graphics image.I need the camera data on the VIP0_HDCOMP path. I could'nt see this implementation in the examples as it is not exactly following the hdvpss main software architecture.

I am trying to capture it from using the gstreamer "omx_camera" plugin.

Can you please help me on solving the issue in  the writeback of my camera data?

Thanks In Advance

Sanju

Hello,

Do you check this example CaptureCompWb_main.c?
It seems it is using instID = VPS_CAPT_INST_VIP0_HDCOMP.

In the default EZSDK there is no element om_camera. I am not aware with it.

BR
Margarita

Hi Margarita,

Thanks For the Reply

I checked all the examples you mentioned.

I am working in a different scenario of write-back path capture of TI8168 unlike ezSDK  examples shown. We are using the omx_camera (gst plugin) to capture the data. We are capturing the data from the VIP_PORT0 (which is our Camera Port) and streaming it to HDMI path and taking the data from the writeback path(VIP0_CAPT_INST_HDCOMP). We have set the input source as (inDataFormat=FVID2_DF_RGB24_888) and the outStreamInfo.dataFormat=FVID2_DF_YUV422I_YUYV. We are enabling the both the pipelines from the gst-launch application like this

"gst-launch omx_camera vif-mode=16BIT ! "video/x-raw-yuv, format=(fourcc)NV12, width=1920, height=1080, framerate=60/1, buffer-count-requested=4" ! omx_mdeiscaler name=d d.src_00 !"video/x-raw-yuv, format=(fourcc)YUY2, width=1920, height=1080" ! omx_ctrl display-mode=OMX_DC_MODE_1080P_60 ! omx_videosink sync=false omx_camera input-interface="VIP2_PORTA" vif-mode=24BIT ! "video/x-raw-yuv, format=(fourcc)YUY2, width=1920, height=1080, framerate=30/1, buffer-count-requested=4" ! filesink location=wrbk.yuv"

I will enable all the path through these sysfs calls

"echo 0 > /sys/devices/platform/vpss/graphics0/enabled
echo 0 > /sys/devices/platform/vpss/display0/enabled
echo 0 > /sys/devices/platform/vpss/display1/enabled
echo 5 > /sys/devices/platform/vpss/system/tiedvencs
echo 2:hdmi,dvo2 > /sys/devices/platform/vpss/graphics0/nodes
echo vcompmux:hdmi,dvo2 > /sys/devices/platform/vpss/video0/nodes
echo 1 > /sys/devices/platform/vpss/display0/enabled
echo 1 > /sys/devices/platform/vpss/display1/enabled
echo 1 > /sys/devices/platform/vpss/graphics0/enabled"

VIP2_PORTA selectig the HDCOMP path(done through the hdvpss code).

I am not getting any frames from the HDCOMP path if I streamInfo.dataformat selected as FVID2_DF_YUV422I_YUYV . I am getting the RGB capture data from the same write-back path if the streamInfo.dataformat selected as FVID2_DF_RGB24_888.

I need to enable the hardware to do the color-space conversion by selecting the outStreamInfo.dataFormat=FVID2_DF_YUV422I_YUYV.

Can you please help me to resolve the issue?

Thanks In Advance

Hello,

In the default EZSDK there is no omx_camera.
With the default EZSDK we are using v4l2src (v4l2 capture) when we are using gstreamer.

Could you provide more information about omx_camera element?

BR
Margarita

Hi,

We are trying to implement writeback capture using Blender (DVO2)-VIP Write back Capture Path, to get the capture of blended grpx data. We have RGB888 from the HDCOMP and we are looking for YUV420 as the output format by enabling Color Space Converter.

We are able to get the RGB output partially via the Vcore_vipResAllocSingleChRgb888 path from the HDCOMP. If we try to use Vcore_vipResAllocSingleChRgb888PathYuv420Out or 422 paths there is no frame output available. More debugging shows that whenever we enable the color space converter in this path the issue happens,

The data path seems correct from HDVPSS registers when configured.
Does any one faced this issue or any workaround for this.

Thanks,
Bibin B

Try configuring muxes in the blanking period..

Rgds,

Brijesh

Hi Brijesh,

We checked the muxes from register level and path from HDCOMP to VPDMA seems to be configured properly. But ones CSC is enabled for R2Y in VIP subsystem the HDMI display is getting stopped and no data comes in HDCOMP. (Frames are coming if input and output in VIP subsystem is configured to RGB888. Also CSC is disabled)

Hi Bibin,

I was not asking about muxes, i am sure muxes are configured correctly, but are they configured at the correct time? Muxes are part of the non-shadow register, so they should be configured in the blanking region only.. I think this is not taken care. could you configure them in blanking area and see if it works.

Regards,
Brijesh

Hi Brijesh,

By blanking region, do you mean to configure the muxes in the timeperiod between the capture of 2 frames? Can you provide more details of same or do you have any example on how to do this in the hdvpss firmware?

We are testing using the openmax gstreamer plugin from EZSDK.

Also we have seen that the gstreamer omx_videomixer is using the OMX.TI.VPSSM3.VFPC.INDTXSCWB component.

Is there any way to select the HDCOMP HDMI Composited Path Input in the scm_m_wrbk_select and get the HDCOMP data back as YUV using this plugin?

Regards

Bibin B

Hi Bibin,

Do you have access to the hdvpss source code? Are you comfortable updating driver code? 

Rgds,

Brijesh

Hi Brijesh

Yes we have access to complete hdvpss firmware source. We are ok to update the driver code.

Regards,

Bibin B

Hi Bibin,

Can you call the API "Vps_captDoDisSyncStartSequence" from the "Vps_captMakeList" API and see if it works?
This API will program the muxes in blanking region.

Regards,
Brijesh

Hi Brijesh,

Thanks for the suggestion.

We have tested this change. But still RGB888(HDCOMP) input to YUV422 output capture is not working as previously.

RGB888 input to RGB888 output is working with and without these changes.

Regards,
Bibin