• State
  • Locked Locked
  • Replies 1 reply
  • Subscribers 98 subscribers
  • Views 239 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Can DM365 be used to translate a non standard YCbCr video stream into a SMPTE274? What would be the latency associated with this?

Charles McCallum
Intellectual 2620 points

Out of our Camera:  1080p30  YcBcR

A 30 Hz Frame rate, over a 20 Bit BUS consisting of:

·         66Mhz Clock

·         16 Bit Video BUS

·         HSYNC

·         SYNC

·         DE

This signal has shortend the blanking. That’s how they clock the data out at a slower rate.

The Cameras 66MHZ SMPTE274, 16 bit signal; has a blanking of 66288

 

 

We want to output to match the SMTPE 274M standard (1080p30)

Add the Blanking and reclock the data at 74.25 MHZ clock

16 Bit Video BUS

HSYNC data rate stays the same.

VSYNC stays the same (30Hz)

DE

 

Note: The 274M spec is 2200 pixels x 1125 lines = 2,475,000 samples per frame.

  • 0
    TI__Mastermind 41665 points

    What you are asking to do sounds like a fairly straight forward rate conversion, no scaling, color space conversion, or processing required. This seems a bit simple for a DM365, you could probably get away with a lower cost DM335 for this lone operation, unless you are doing some unmentioned h.264 compression/decompression.

    In any case this sounds perfectly feasible for the DM365 or for most of our VPSS (VPFE/VPBE) based parts, it would just be a matter of modifying the capture and display drivers to handle the formats and camera/output hardware configuration and than running a simple loopback program to copy frames between the two. The latency would vary depending on how the capture and display are synchronized and the buffering scheme implemented, somewhere between 1 frame and 3 frames of time, since you have the capture port filling a buffer, and the display port copying out of a buffer, and a software thread copying between the capture and display buffers.