Preview + OSD on Omap3530

Amit,

It does not surprise me that there is 100ms of latency since it is desirable to at least double buffer and preferably triple buffer between the input and output in order to reduce tearing whilst still maintaining the most optimal frame rate. Since each frame is 33ms having a latency of around 100ms is possible.

There may be ways to reduce this latency by reducing the number of buffers, or using a single buffer for read and write, but this scenario will have its own issues, namely tearing and/or stuttering due to the asynchronous nature of the input to output.

Just to check... do you see 100ms latency or 100ms per frame processing delay? Latency maintains high frame rates but they are delayed with respect to the input. Truly delayed images will give low frame rate updates.

If it is a long processing delay then it is possible that the application is doing frame buffer copies rather than using pointer manipulation. I believe there is a way to ensure the CODECs use pointer management rather than doing buffer copies but I can't recall what it is at the moment.

Regarding the OSD, yes it is possible to overlay up to three frame buffers. Have a look at the following Wiki for what the hardware is capable of. I am not 100% sure how this is exposed in the Linux drivers though unfortunately.

http://processors.wiki.ti.com/index.php/Display_Subsystem

BR,

Steve

Thank you Steve,

I am not using any codec. just video in -> video out.

I did the test again and this time I connected my PAL camera both directly to a TV and to the OMAP input (which is later connected to a 2nd TV).

 The camera is capturing a clock which is updated every 20 msec. The difference between the 2 screen as we observe was between 50 -90msec.

I am using a buffer for the input from the ISP and then pass it to the video pipeline.

I suspect that there is double/triple buffering in this pipeline to avoid tearing affect. How can I reduce this delay? is it configurable?

Amit,

I am reaching the limit of my knowledge now since I am really a hardware guy.

What framework are you using for capture and siaplay (V4L2, fbdev etc...)?

If you simply want to display the camera and don't care about tearing of the image (caused by the asynchronous input and output) then you could adjust the frame buffer pointer to simply point to the same buffer that the camera is capturing to.

I do not know the "correct" way to do this through the framework, but from a hardware perspective it is simply a matter of ensuring the display controller is configured correctly for the source format and is pointed at the right memory.

I will see if I can get someone else involved who has a much better understanding of the frameworks than I do.

BR,

Steve

Steve,

Thank you for your efforts.

I am using V4L2 for both captiure and display, but if is it possible via FBDEV , then it is fine with me. I will realy appreciate it if you can find someone who have better knoledge in those drivers.

another question is that:

Is it possibe to use the preview mode, and still adding OSD or color keying on the output?

Thanks,

amit.

Amit,

The input (capture) and output (display) sub-systems are completely independent so can be used any way you want (from a hardware perspective at least).

If you look at the Wiki I referenced a few posts back you will see that the display sub system really only combines up to three frame buffers and combines them to final outputs. How you generate the source data in the first place is irrelevant.

Now, from a software driver perspective I am not sure what is exposed and what you would need to hand craft.

I did pass the post to some other people but currently they are out of the office so it may take a little time to respond, sorry.

BR,

Steve

Amit,

  It should not be a problem to use the V4L2 capture driver and display via either fbdev or V4L2 also.  Please read through the Users Guide document which documents these drivers for Linux in the Linux Platform Support Package.

http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/dvsdk/DVSDK_3_00/latest/index_FDS.html

Regards, Clay

Hi Clay,

I read documentation and it seems that direct preview from the capture driver (ISP) to the DSS is not yes supported by the current V4L2 driver.

Ofcourse I can capture the frame from the ISP and then send it to the V4L2 driver of the DSS, but then the delay caused by the triple buffer of each side is killing me. (200msec)

If you know a better way to do it or direct me to another source I will be grateful.

Amit.

Amit,

Triple buffering is the only way to ensure that you do not get either tearing nor stuttering.

If you can live with the possibility of tearing then you could potentially configure the ISP to use a single buffer then simply point the DSS to this buffer. I am not sure how to do this through the drivers, but the hardware is certainly capable of it.

This will certainly show image tearing though, but the latency will be guaranteed to be less than a frame period.

Moving to double buffering will eliminate tearing, but will cause stuttering. This methodology has a latency of between 1 frame and 2 frames.

Clay may have some ideas on how to get the drivers to implement each of these methodologies through the drivers, otherwise you may need to write your own interrupt handlers to perform the buffer management.

BR,

Steve

Amit,

   I think that some frame copying is probably unavoidable.  The fastest way to do this should be to use the system DMA.  Have you tried that?

If you are planning to use OpenGL ES to generate your graphics overlay, you might want to copy the video frame data anyway into a format that can be used for texture streaming.  Otherwise, using the system DMA is probably the best approach.

Regards, Clay