Simultaneous H.264 encode and loopback?

Here's a related Forum thread:

http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/717/t/152211.aspx

Regards,
Marc

Marc,

Thanks for the pointer.

Looks like the situation described in that thread is for a capture --> encode --> decode --> display chain, with a latency that's beyond what we're shooting for.  Given our latency requirements, we'd like to eliminate the overhead associated with the decode, and simply loop the incoming signal back out for immediate display.

capture ----> encode --> mass storage
         \--> display

Any idea if such a configuration is feasible?

Regards,
Cory 

Hi,

I may not have understood your questions fully. EZSDK demos same thing where it caputres-->encode-->writes to SATA

                                                                                                                                                            |

                                                                                                                                                            | ---> Display

Are you trying to do this with V4L2 examples or something like that. Currenly capture to display latency is  high and we are trying to reduce that in next EZSDK release.

Regards,

Hardik Shah

Hardik-

Thanks for the reply.  What we're trying to determine is the minimum latency we can achieve for a "live preview".

Our design is required to capture an incoming 1080p30 or 1080i60 HD/SDI signal and encode it as H.264 for storage to disk.  It has been requested that we provide a "live preview" of the video which is being recorded as an HD/SDI output.  We can tolerate latency as part of the encode and write to mass storage; the video is being recorded for later playback on another system.  We can not tolerate latency on the "live preview"; ideally we'd like this preview to lag the incoming HD/SDI by no more than 4 frames (~133 msec).

What we're trying to determine is whether or not we can simply "loop-back" the incoming video in the front-end of the 8167 without having to decode the encoded video, and also use the captured frames as inputs to the H.264 encoder.  This would (should) allow us to meet the latency requirements for the "live preview", and eliminate the need for additional loop-back routing / muxing external to the 8167.

We've been testing using a Spectrum Digital 816x/389x EVM.  Is there an EZSDK demo for that platform which would allow us to do an initial evaluation of something similar to what we're trying to do.

Thanks again.

Regards,
-Cory 

Hi,

EZSDK provides exactly same demo what you are looking for. Its operational on DM8168 with a IO expansion daughter card on it. Latency figures will be slight higher but we are working towards reducing it. You can download EZSDK at http://www.ti.com/tool/linuxezsdk-davinci

I dont understand your second para completely. You will have to decode the encoded video and then you can display it.  HDVPSS doesn't contain internal decoder. You will have to use HDVICP to decoder the incoming encoded video. These all use cases are part of EZSDK demo.

Regards,

Hardik Shah

Hardik,

If you assume that the video stream comes in as "raw" video (from some camera). What is the latency to just capture it and send it to the display. No video encoding or decoding is required.

Thanks,
Alex