Input Video Multiplexing

Chris,

Which video decoders are you planning on using?

How are you planning on synchronizing the video decoders?

Even if they use the same reference clock the output data clocks from the 2 decoders will be different since the video streams will be asynchronous to each other.

Most video decoders implement internal PLLs which lock to the incoming video signal and re-generate their output pixel clocks based on this.

The TVP5158 is able to re-clock the two video streams together, but even there the individual data streams will move with respect to each other due to the asynchronous nature of the source video signals.

BR,

Steve

Well, I've used the SAA71115 in the past, but would probably use the TVP5146 to keep the drivers the same as my reference board.

In the last design, I added a hardware based TBC circuit to Drop/repeat frames so that the data clock was synchronous 27MHz. This worked on the output of the video decoder.   I was hoping that this could be done internal to the 365, but I could see that being trouble with multiple inputs.  The TBC circuitry also allowed for some digital test patterns to be displayed when video was not present on the decoder input.

This of course, would only synch up the pixel clock, as the fields and lines would still by asynchronous, but I assume that the BT656 descrambler could handle that.

So, assuming this approach, can I use the two seperate input busses?  Oh, and before you ask, the TBC circuitry is on the video front end daughter card, so multiplexing them would require circuitry on the motherboard, which I'd prefer to avoid as real estate is an issue.

Many thanks for quick response.

-Chris

Chris,

I don't know much more about the input buses unfortunately, so will need to defer on this part of the question to someone more knowledgeable .

Regarding your TBC, if this is a frame based TBC then you should be able to align the frames from the two video sources by, as you say, dropping/repeating frames.

This may not be necessary, and simple re-clocking may be sufficient where the two streams are merged into a single clock domain and the async effects are accounted for by increasing/decreasing the number of blanking 'pixels'. This does not require any substantial memory since it only needs to accommodate the slippage between the two clock sources over a line, which is only likely to be one or 2 pixels max.

This does assume that the DM can correctly decode 2 independent 656 streams though, otherwise a fully aligned frame buffer would be needed.

BR,

Steve

Hi Steve,

thanks for the response.  I didn't think you could pad the 656 stream with extra 'blanking' pixels.  That would certainly help to reduce external memory requirements,  In fact, if that were the case, I could probably accomodate the entire TBC within a small FPGA.

Regardless, I'm still left with the original question, Can I use the two busses for inputing two video's, or do they have to be muxed?

Can you point me to someone who might be able to answer this?  Like I said originally, seems odd that this is not supported, based on the flexibility of the input circuitry.

Perhaps, I should be looking at a different chip?  One more suited to encoding multiple streams perhaps?

Chris,

If you do not have a frame buffer then this is actually ALL you can do if you want to re-synchronize 2 streams together into a single clock domain. This is basically what the TVP5158 does. The TVP5158 can additionally interleave the data at 2x clock (4x for quad inputs) on either a line basis or on a pixel basis. The principle is the same though, i.e. bringing multiple async streams into a single clock domain.

The receiver should look at the SAV and EAV codes to determine where the active video is and basically ignore the blanking times. I have, however, seen some devices incorrectly assume that the blanking times are fixed. This is extremely dangerous since many many video sources do not actually adhere to the NTSC standard. A VCR player in fast forward is a simple example of this, but it occurs with even simpler cases such as un-plugging and re-plugging the inputs to the decoder.

The issue then becomes... can the receiving device truly handle 2 independent streams? This is what I am not sure of on the DM365.

I will try to find the correct person to answer whether 2 streams are supported.

BR,

Steve

if you add the cost of the  TVP5158  (9$)  to the cost of the DM365 you would spend the same as if you would go in the DM64x family where they have chips with 2 video input ports.  But please do not trying to stop for a solution :)  I am in a similar situation.

Agreed.

The only reason I was mentioning the TVP5158 was to explain that padding is how the 58 achieves clock re-synchronizing without a frame buffer.

Of course, your above price analysis does also actually include the video decoder cost too, which you would still need with the DM64x solution.

Small FPGA devices can be found for a lot less I think, especially in volume and as I have previously mentioned, the re-clocking does not require very much logic not any large buffers.

BR,

Steve