Using nTimeStamp and nTickCount in ezsdk_dm814x-evm_5_05_01_04

Hello,

Krunal Patel_11 said:

What is the purpose of nTickCount field and why it is currently not used?

I should check.

Krunal Patel_11 said:

Is the value of nTimeStamp depends on ARM CPU usag

nTimestamp gives the value as provided by the capture driver.

Check also :

BR

Margarita

Hello,

    OMX_U32 nTickCount;         /**< Optional entry that the component and
                                     application can update with a tick count
                                     when they access the component.  This
                                     value should be in microseconds.  Since
                                     this is a value relative to an arbitrary
                                     starting point, this value cannot be used
                                     to determine absolute time.  This is an
                                     optional entry and not all components
                                     will update it.*/

Check component-sources/omx_05_02_00_46/include, file OMX_Core.h

BR

Margarita

Hello Margarita,

I have already checked the definition of nTickCount in OMX_Core.h.

But my question is:

1. In capture_encode demo why 'nTickCount' is '0'?
2. Also when I checked the value of nTimeStamp its value increases either by 16 or by 24 even if the frame rate is 60 fps. Can you please let me know the reason for this? Will this field be updated after every frame?

Thanks,

Krunal

Hello Margarita,

Any updates on the above queries? Kindly find the table for the different nTimeStamp values and the difference between them. Ideally the difference should be 16 or 17. But sometimes it is 24.

Please let me know if you need more details.

Thanks,

Krunal

Hello,

It seems that the queued  buffer to the capture driver will dequeued after a callback from the capture driver. It gives a callback after 8ms.

BR

Margarita

Hi Margarita,

I have few more questions regarding the timestamps and buffers.

1. Can you give us a link to the driver code handling captured buffers from VFCC?
2. Can you give us an explanation of VFCC firmware and driver interaction?
   1. How driver is notified about the new buffer is ready?
   2. How driver is aware of buffers timestamp?
3. Why nTimeStamp resolution is 8 ms?

Thanks,

Krunal

Hello,

The VFCC code is in the overlay package which is under NDA and can not be discussed in the public forum. Contact your local FAE or TI representative for information how can be obtain it.

BR
Margarita

Hello Krunal,

Krunal Patel_11 said:

Can you please let me know how and where are the buffers filled with data containing video frame, timestamp, etc.?

Are you mean in the code?

BR

Margarita

Hello,

You could check omx_vfcc_drvif.c in the vfcc component folder and in the component-sources/hdvpss_xx_xx_xx_xx/packages/ti/psp/vps/drivers/capture folder (vps_capture.h: IOCTL_VPS_CAPT_CFG_TIME_STAMPING_FRAMES).

BR
Margarita

Hi Margarita,

Thanks for the information. 

In addition to the above information I have some queries:

1. Can we add a new field along with the video timestamp which can be used to mark the frame number(i.e. sequence number)?
2. Can you please confirm that the timestamp values will be accurate in case of CPU spikes?
3. Can there be cases when the frames can be lost between driver to user space during CPU spikes(high CPU usage)?

Thanks,

Krunal

Hello,

I haven't try this but you could try.
The CPU load could increase since for every captured frame an interrupt would be generated.

BR
Margarita

Hi Margarita,

From your previous response "It seems that the queued  buffer to the capture driver will dequeued after a callback from the capture driver. It gives a callback after 8ms."

Can you please let us know if there is any way by which we can reduce the callback time of 8ms?

Thanks,
Krunal

Hello,

The driver team response is:

"It is happening because, the fractional part of 0.667 accumated over 12 frames.
12x0.667 = 8 and this is resulting is 24(16+8)"

BR
Margarita

Sharing some more information from our side regarding the debugging.

When we print timeStamp values in HDVPSS firmware we get a difference of 8ms after every 5th or 6th frame, while in application it is after 10th or 11th frame. We have put the debug prints in function "Vps_CaptTskPutCaptFrm" of file vpsdrv_captureList.c of capture driver. Please find the below code snippet for your reference:

if ((NULL != pChObj->pPrevFrame) &&
    (TRUE == pChObj->evenFieldCaptured) &&
     (pChObj->pPrevFrame->channelNum !=
        VPS_CAPT_DROP_FRAME_CH_ID))
{
    frameCaptured = TRUE;
    Vps_printf("Debug : nTimeStamp = %d\n",Clock_getTicks());
    VpsUtils_quePut(
        &pObj->fullQue[Vps_captGetStreamId(parseDescInfo->lChannel)],
        pChObj->pPrevFrame,
        BIOS_WAIT_FOREVER);
    pChObj->pPrevFrame = NULL;
}

Also we have observed the above behavior when input is NTSC.

BR

Krunal