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.

Three RAW capture video port data acquisition at the same time?

I made three video port work as raw capture port in DM648, and I used an FPGA to feed video data to the three video ports at the same timing sequence. So the three video ports will operate at the exact same time in parallel only except for the different captured data. And my DSP code is written based on PSP video port driver and is as follows:

 

void tskVP0RawCap(void)

{

    // Start capture operation

    if (IOM_COMPLETED == status){

        status |= FVID_control(capChInfoRaw0.chanHandle,

                               VPORT_CMD_START,

                               NULL);

    }

    else{

        LOG_printf(&trace, "Failed at VP0 capture startup\n");

    }   

 

    // Forever loop

    while(1){

        // Capture buffer will return a filled buffer

        status = FVID_dequeue(capChInfoRaw0.chanHandle, &(capChInfoRaw0.frame));

        if (IOM_COMPLETED != status) {

            LOG_printf(&trace, "Failed at VP0 capture task\n");

        }

 

        SEM_post(&SemVP0CapComplete);

    }

}

 

void tskVP1RawCap(void)

{

    // Start capture operation

    if (IOM_COMPLETED == status){

        status |= FVID_control(capChInfoRaw1.chanHandle,

                               VPORT_CMD_START,

                               NULL);

    }

    else{

        LOG_printf(&trace, "Failed at VP1 capture startup\n");

    }   

 

    // Forever loop

    while(1){

        // Capture buffer will return a filled buffer

        status = FVID_dequeue(capChInfoRaw1.chanHandle, &(capChInfoRaw1.frame));

        if (IOM_COMPLETED != status) {

            LOG_printf(&trace, "Failed at VP1 capture task\n");

        }

 

        SEM_post(&SemVP1CapComplete);

    }

}

 

void tskVP2RawCap(void)

{

    // Start capture operation

    if (IOM_COMPLETED == status){

        status |= FVID_control(capChInfoRaw2.chanHandle,

                               VPORT_CMD_START,

                               NULL);

    }

    else{

        LOG_printf(&trace, "Failed at VP2 capture startup\n");

    }   

 

    // Forever loop

    while(1){

        // Capture buffer will return a filled buffer

        status = FVID_dequeue(capChInfoRaw2.chanHandle, &(capChInfoRaw2.frame));

        if (IOM_COMPLETED != status) {

            LOG_printf(&trace, "Failed at VP2 capture task\n");

        }

 

        SEM_post(&SemVP2CapComplete);

    }

}

 

The three tasks are registered in DSP/BIOS, and will operate with a lower priority than the processing task, which will be pended for the three semaphores: SemVP0CapComplete, SemVP1CapComplete and SemVP2CapComplete. The processing task code is as follows (only the first several lines) :

 

void tskVideoProcessing(void)

{

    // Forever loop

    while(1)

    {

        // wait for capture completion

        SEM_pend(&SemVP0CapComplete, SYS_FOREVER);

        SEM_pend(&SemVP1CapComplete, SYS_FOREVER);

        SEM_pend(&SemVP2CapComplete, SYS_FOREVER);

 

              // processing starts here

              ………

}

}

 

Now the program executes correctly, but the frame rate is lower than the input video data. The expected frame rate is 60Hz but now I could measure only 37Hz approximately based on a timer. And I analyzed the execution graph and used profiling to trace the CPU cycles, I found that the three task consume a lot of CPU time on function FVID_dequeue(). Since the three capture port operate on the same timing, so if one of the three ports can ‘dequeue’ one frame back, the rest two ports should ‘dequeue’ the just captured frame back immediately. However as the code listed above, the DSP seems to capture three frames buffers on a serial sequences, which will lose some video frames.

 

What will the code look like if I want the three video ports to capture video data in parallel at an exact same timing?

  •  

    Can you try the following and let me know your observations?

    1. Have you tried measuring the frame rate without the processing task? If so what is the frame rate is that case?

    2. Is the frame rate proper if only one video is captured at a time (without the processing task)? Check this for all the video ports separately!!

    Basically I want to narrow down the issue to driver/hardware or with the application.

     

    Regards,

    Sivaraj R

  • I have to say that my earlier judgment is too arbitrary. I made the following experiments:

     

    A. All three RAW Capture ports are functioning, and the processing task is simply copying data from source address (the captured video data) to destination address using memcpy() function. Both the two memory area is located in DDR2. The measured FPS is 24~25.

    B. All three RAW Capture ports are functioning, and the processing task is simply copying a small data block in L2 SRAM to destination address using memcpy() function. The captured video data in DDR2 is not used at all. The measured FPS is 37~38.

    C. Only one of the three RAW Capture ports is functioning, and the rest two ports do not queue/dequeue/SEM_post/SEM_pend, so they have no effects on CPU load. The processing task is simply copying data from source address (the captured video data) to destination address using memcpy() function. Both the two memory area is located in DDR2. The measured FPS is 24~25.

    D. Only one of the three RAW Capture ports is functioning, and the rest two ports do not queue/dequeue/SEM_post/SEM_pend, so they have no effects on CPU load. The processing task is simply copying a small data block in L2 SRAM to destination address using memcpy() function. The captured video data in DDR2 is not used at all. The measured FPS is 55~56.

     

    Note that all the experiments is on a debug executables basis, but I turn on all the speed optimizations in CCS build options. The performance of the release version is similar to the debug version.

     

    I have to say that fetching data from DDR2 is indeed time consuming: from A to B or C to D, the only difference is whether to fetch the source data in DDR2 or not. While from A to C, the FPS is the same, so the asynchronous capture port operation does not affect the performance much as I thought before, however from the execution graph, the three ports indeed consumes a lot of CPU tick sequentially

     

    Even in the D situation, the FPS could not reach the expected 60Hz either. When the memcpy is added, and the other two capture ports dequeue is added, the FPS is becoming lower and lower.

     

    So what should I do to find the cause and fix this problem?

  • I think the issue could be some thing more global rather than to do with VPORT capture.

    Could you check the following:

    1. CPU frequency is set properly?

    2. Cache is programmed properly?

    3. DDR clock and other timings properly configired?

     

    Which version of PSP driver are you using?

    I also wanted to know the FPS @ driver level.

    To do that, can you add a counter in the PSP capture driver ISR, run the test for say 1 minutes and look at the value of the global counter after this?

    In file pspdrivers_1_10_01\packages\ti\sdo\pspdrivers\drivers\vport\src\vportcap.c, add a global variable counter at the start of captureEdmaISR() function.\

    Let me know if you need any more detailed steps to do this.

  • The PSP driver version is 1.10.01. I checked the following configurations:

    1.       For thermal reason, the PLLM register of PLLC1 is configured to 13h, with an external 30MHz clock, the DSP frequency is 600MHz. I tried 900MHz, the performance is nearly the same. Is it true that the performance of memcpy() is irrelevant with DSP frequency?

    2.       The cache is configured correct. In the TCF file: “bios.GBL.C64PLUSMAR224to255 = 0x0000ffff; ”. If I set this value to 0x00000000, the measured FPS is about 12. So cache is functioning.

    3.       On board DDR2 chip is MT47H32M16BN-37E, and DDR2 controller is configured as CAS_Latency=4, Bank=4, Data Bus Width=32, Page Size=1024. The timing registered is not configured, so the default parameter is used. Since DM648 EVM also uses Micron DDR2, so I think the default timing parameter is OK.

     

    As you said, I add an global variable in vportcap.c, the times of ISR called is about 225 in all the 4 situations mentioned in my last thread. Since there are three capture ports, so 225/3=75Hz. The provided video is fixed at 1024X768@60Hz, so I think the measured results is somehow impossible.

  • 75 Hz/2 comes around 37-38 FPS which you have mentioned in previous communication. So there seems to be some logic behind it!!

    Can you provide the driver configuration, the timing of the input video and how the signals from the FPGA are connected to the VPORT?

    This will help me in understanding the problem a bit more.

     

    I first wanted to narrow down the issue for not getting 60 FPS for single video capture. Then we can look in to 3 video capture.

     

    Regards,

    Sivaraj R

  • Driver configuration:

    #define NUMPIXELS                           (1024)

    #define NUMLINES                            (768)

    #define HDIM_CAP_RAW_16BIT{                                             \

        VPORT_MODE_RAW_16BIT,               /* cmode:3      */              \

        VPORTCAP_BPK_10BIT_ZERO_EXTENDED,   /* bpk10Bit     */              \

                                                                            \

        TRUE,                               /* SSE          */              \

        1000,                               /* blankperiod  */              \

                                                                            \

        NUMPIXELS >> 1,                     /* lineSz       */              \

        NUMLINES,                           /* numLines     */              \

        (NUMPIXELS >> 4),                   /* thrld        */              \

                                                                            \

        3,                                  /* numFrmBufs   */              \

        128,                                /* alignment    */              \

                                                                            \

        NULL,                               /* segId        */              \

        NULL                                /* hEdma        */              \

    }

     

    Input video timing:

    Video source is standard 1024X768@60Hz RGB888 format video. FPGA receives this video and write video data in three separate FIFO (R_FIFO, G_FIFO and B_FIFO). When there are any data in the three FIFO, FPGA will read them out and transfer to FPGA VPORT. Note that the FIFO write side data width is 8 bits (one color component of one pixel), and read side data width is 16bits (one color component of adjacent two pixels), the width resizing is done inside the FIFO. Since each pixel is composed with RGB, so the function and timing of the three FIFO are identical, therefore the three VPORT will also work in the same timing.

     

    FPGA to VPORT connection:

    There are three VPORT connected to FPGA. They are VP0, VP1 and VP2. For each VPORT, 16 bits data to VPORT DATA, and 1 bits control to VPROT CTL0, and 1 bits clock to VPORT CLK0. All the mentioned 18 signals are from FPGA to DSP.

    In RAW capture mode, CTL0 will act as CAPEN, and each time the FPGA reads out one 16bits data, the CAPEN will be asserted for one clock period.

     

    In the D situation, the FPS is 55~56, so I think single VPORT dataflow is almost correct. The problem is when three VPORT work at the same time, the FPS falls down a lot.

  • What is the frame rate at the driver level when you are getting 55~56 FPS in single VPORT operation? Are you still getting twice the FPS at the driver level in this case?

    The driver configuration seems to be fine.

    Kindly try to narrow down the issue either to the application or with the driver.

    If you have dummy application (just doing driver queue/dequeue operation), then the application FPS and driver FPS should match.

    I could not comment much with the information I have with me now.

  • The low frame rate could also be because of capture overrun errors. Since you are running 3 VPORT capture @ 60 FPS, it could be a probable reason for this.

    Could you confirm the same by registering capture overrun error callback with the VPORT driver and check whether the driver notifies the application of this?

    We can then analyze why this is happening.

     

    Regards,

    Sivaraj R