ipnc_rdk_v3.2 Data Path Problem

Hi Ravikiran,

could you give us a complete image on your data flow?

Where comes from the YUV data? You have modified NullSrc to read it from somewhere?

If I just take the two link chains you gave above, yes it's possible to run them in parallel and you don't need to modify anything for the first use case.

The ISP link takes RAW data from DDR, converts it to YUV and outputs from RSZ to DDR, it runs independently from the camera link and RAW capture. 

  

Zhuoran Dai,

Thank you for the reply.

"Where comes from the YUV data? You have modified NullSrc to read it from somewhere?"

NullSrc has its own buffers, and based on channel configs what we pass to NullSrc, it can output the data. Since I need YUV data, I configured NullSrc to output YUV data.

Here my specific doubt is "IS that possible to confogure multiple channels of ISP(isif/ipipe etc)? Assuming I have connected CSI2 and CPI sensors together!!"

Hi Ravikiran,

it's still not clear for me.

In our RDK NullSrc link is used to debug and just outputs dummy data. I don't think you use it as it is and you may have made some modifications on it to read data from somewhere, where the YUV data you mentioned comes from?

 "IS that possible to confogure multiple channels of ISP(isif/ipipe etc)? Assuming I have connected CSI2 and CPI sensors together!!"

Currently we don't support this in our RDK.

Zhuoran Dai,

Thanks for you precious reply.

By Tracing NullSrcLink, NullSrcLink_fillDataPattern() is called while creating the buffers. This function fills some pattern to the specified buffers.
I dont care about what data it is. I just want to see data getting encoded/encoder thread running.
So I assume, YUV data is filled in those NullSrcLink  buffers while Create() itself & I use it in future as long as my thread is running.

NullSrcLink just outputs dummy data, it's upon to you to specify what data format you would like to output in the create arguments so the following link will process the data assuming that format, the actual data content is the same.

During your debug task you can run these two data flows in parallel, but I can't tell you the feasability in your real product unless you specify where your YUV data actually comes from.

Zhuoran Dai,

"NullSrcLink just outputs dummy data, it's upon to you to specify what data format you would like to output in the create arguments so the following link will process the data assuming that format, the actual data content is the same."

Yes, I have configued it for yuv. Please find my NullSrc Link configurations below.

        NullSrcPrm.outQueParams.nextLink = ipcOutVpssId;
        NullSrcPrm.tilerEnable = FALSE;
        NullSrcPrm.numOutQue = 1;
        NullSrcPrm.timerPeriod = 33;
        NullSrcPrm.inputInfo.numCh = 1;
        NullSrcPrm.inputInfo.chInfo[0].bufType = SYSTEM_BUF_TYPE_VIDBITSTREAM;
        NullSrcPrm.inputInfo.chInfo[0].codingformat = 0;
        NullSrcPrm.inputInfo.chInfo[0].dataFormat = SYSTEM_DF_YUV420SP_UV;
        NullSrcPrm.inputInfo.chInfo[0].memType = SYSTEM_MT_NONTILEDMEM;
        NullSrcPrm.inputInfo.chInfo[0].startX = 0;
        NullSrcPrm.inputInfo.chInfo[0].startY = 0;
        NullSrcPrm.inputInfo.chInfo[0].width = 1920;
        NullSrcPrm.inputInfo.chInfo[0].height = 1080;
        NullSrcPrm.inputInfo.chInfo[0].pitch[0] = 1920;
        NullSrcPrm.inputInfo.chInfo[0].pitch[1] = 1920;
        NullSrcPrm.inputInfo.chInfo[0].pitch[2] = 0;
        NullSrcPrm.inputInfo.chInfo[0].scanFormat = SYSTEM_SF_PROGRESSIVE;

And I modified the Flow as below.

NullSrcLink-->ipcOutVpss(m3vpss Out)--> ipcInVideo(m3 In)-->encoder-->ipcBitsOutRTOS-->ipcBitsInHLOS.

Other Links I removed, Since they are not required. Is that flow is correct?

Appreciate your help.

Hi Zhuoran Dai,

Please can you tel me, what should be my NullSrcLink configuration, if I want to use NullSrc instead of CameraLink and Connect the NullSrcLik to ipcOutVpssLink... 

Appreciate your help.

Thank you.

NullSrcPrm.inputInfo.chInfo[0].bufType = SYSTEM_BUF_TYPE_VIDBITSTREAM;

I think the above item is not correct, SYSTEM_BUF_TYPE_VIDBITSTREAM means encoded bit stream.

 

But again, please tell us what is the data flow in your real product. NullSrc is just used for simulation you need to figure out how you feed the real data.

Hi Zhuoran Dai,

Thank you for the response.
"But again, please tell us what is the data flow in your real product. NullSrc is just used for simulation you need to figure out how you feed the real data."

Since I don't have the sensor available with me right now, I am planning to use Null Src. Actual data path will be look like something as below, when I get the sensor in Place.

PATH1: sensor(1) --> CameraLink --> Alg. ProcessData -->ipcOutFrames(vpssOut)--.ipcInFrame(A8In)
PATH2: sensor(2) --> ipcM3Out(vpss) -->ipcM3In(M3)-->Encoder(M3)-->ipcBitsOut(M3)-->ipcBitInA8)-->Streaming using RTSP

Both the paths I am trying to enable simultaneously.

I would like to ask you one more query this.

my PATH1 and PATH2 are working fine now, when I try running it separately.  But If I combine both PATHS, Path1 works but not Path2.  How to debug the issue any idea?

Thanks in advance. Appreciate your help.

Zhuoran Dai ,

Thanks for your support ..

I found the issue and it is resolved.

I have a question about data path 2 that is being discussed here:

PATH2: sensor(2) --> ipcM3Out(vpss) -->ipcM3In(M3)-->Encoder(M3)-->ipcBitsOut(M3)-->ipcBitInA8)-->Streaming using RTSP

How do you enable data flow from the sensor to the ipcM3Out(vpss) link directly? Did you write a custom link or module to handle this?

They do work seperately. Issue is fixed. Found a problem i path configurations.

Camera data is not fed to ipcM3Out Link directly. Actually first link is capture link. Output of capture Link is fe to ipcM3Out.