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.

DM355 USING VIDEO DECODER TPV5146

Other Parts Discussed in Thread: TVP5146, TVP5158

We have a 2 PAL/CBVS camera system.

The TPV5146 is set up for a single input and we have an external VIDEO MUX multiplexing the cameras. Both cameras are powered up.  They are also  out of sync with each other. 

The DM355 and TVP5146 are wired up as per the EVM. Y2-Y9 to Y0-Y7 of the DM355. + PCLK

The CCDC is set up for BT.656 capture.

The aim of the product is to MUX the two cameras. and store a frame of each camera into memory ad infinitum.

We grab the 1st cameras frame and then switch to the second then back to the first etc.

When we look at the result, the frames are not vertically synchronised and sometimes not horizontally synched .

Q.

Is there a way to sync  the VPFE when we switch to the next camera so that  the ccdc is waiting for a New SAV ????

I am assuming that the TVP5146 will not have any time overheads appart from 1 or 2 frames.

 

 

 

 

 

 

 

  • In my experience, most video decoders take up to 3 frames to sync when the video on the input is switched. Actual resync time depends on the differences between DC levels of the output sigmnals which vary significantly from camera to camera. Sometimes clamping video inputs to the same DC level helps a bit, but one should still expect up to 3 frames for complete sync, regardless of whether it's an external mux or decoder's internal mux. Bottom line: it's most likely the decoder not syncing, not the VPFE.

  • As Alexander mentions the video decoder will take a few fields to re-lock to the video signal when swapping inputs (by the way, is there a reason you are using an external mux rather than the TVP5416's internal mux?)

    This re-syncing will cause the 656 stream to be mis-aligned momentarily whilst lock is re-established.

    You could possibly monitor the TVP5146 lock status bits to ensure the decoder has locked before you consider the image valid.

    Additionally the TVP5146 has a 'fast lock' control bit which basically causes the decoder to lock quicker to changes in the video signal, but does cause disruptions in the v-sync during the transitions. This may give better results.

    I have a feeling that the only way to be certain that the captured image is valid and from the camera you are interested in is to a) enable fast switch, b) switch the input source, c) reset the capture port, d) wait for completion interrupt.

    BR,

    Steve

  • It sounds like you really want to capture every-other frame from each camera, so that you get two capture streams simultaneously at half the frame rate each.

     

    The approach you're taking isn't going to work for this for reasons posted above. The best you can do with this approach would be to capture a frame from source A, put the CCDC in reset, switch to channel B, re-enable the CCDC, capture a frame, then repeat. Due to the sync times required by the TVP decoder and CCDC itself, you will miss a lot of frames. I'm not sure what the effective frame rate you can achieve is, but it won't  be much.

     

    If you need to be able to capture all of the data from both channels, I recommend you take a look at the TVP5158 video decoder. It has a line-multiplex mode that was designed to work with chips like DM355 with a singe BT.656 input port. Using this mode, and running the CCDC interface at 54 MHz instead of 27, you can capture all the data from both channels simultaneously. Note that there is some software overhead required to de-mux the received data.

     

    If you don't want the SW overhead, then something like McVFE: http://www.nuvation.com/ip/mcvfe.html is what you want. The design of McVFE was originally created for DM6467, but it could be adapted to DM355 relatively easily.

     

     

     

  • Thanks Todd, we will try the sugested methods we will be ok to delay up to 4 frames(2 fields per Frame) (160 mS) to get one good Frame. At present we wait about 12 Frames! Unfortunately can't change the hardware as we have it, so it is up to SW to cross this bridge.(maybe next revision!) Will look at the TVP5158 though,

    Thanks for the help.

     

  • Thanks Steve,

    We are using an external mux because we have designed a universal module with the 355 and TVP. Connector pins were a limiting factor.

    Could you describe in a bit more detail the procedure for checking the TVP lock status. Also are you referring to STATUS 1 bit 4 register 3Ah ?

    What is the method for reseting the capture port?? ( i have to enlighten our software chap!)

    Cheers,

    Tom

  • Thanks Alexander,

    I believe it may be a little of both! I'm not too versed on the VPFE, but what  would be good for the software is a single flag to say that the frame is valid and ready!

    Cheers.

    TC

  • hi,

    Unless the camera's are in sync this will be tough to do.

    One other other option is to use the TVP5158 device which supports upto 4 MUXed D1 inputs and sends the muxed stream in "line-multiplexed" mode.
    The DM3xx video port can capture this muxed stream and then a SW driver can demux this stream line by line.

    Unfortunately we dont have SW driver for DM355, but we do have SW driver for DM365.

    We have reference design which integrates this SW driver
    http://www.udworks.com/home01/eg/product/sub10.php

    More information on TVP5158 can be found here
    http://focus.ti.com/docs/prod/folders/print/tvp5158.html

    So possible options that can be used by you are,
    1. Use TVP5158+DM355 and port TVP5158 demuxing driver from DM365 to DM355
    2. Use TVP5158+DM365, you have a ready made integration of multi-ch video camera capture

    regards
    Kedar

  • Tom,

    Bit 4 is a sticky bit which gets triggered when a loss of lock is found. Once the video is re-locked this bit does not clear and you would need to clear it yourself.

    You should really check all three lock bits h, v and color (bits 1, 2 & 3).

    BR,

    Steve