tvp5158 4ch D1 problem

Gradimir,

Is your signal NTSC or PAL?

-M

My signal is PAL. I think that everything is configured as it should be. I can send tvp5158 register dump for inspection.

Gradimir.

Gradimir,

Most important is register 0xB7, which should be 0x14 for you.

Look at this thread: http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/100/p/162211/595630.aspx for other ideas.

-M

I checked register dump and register 0xB7 is set to 0x14. I saw the thread couple moths ago and basically I have the same problem as you did, showed in frame 5 in the thread. I do not have ghosting effect (I think that deinterlacing is ok), it looks like old frame is mixing with the new one for the same channel (seen on video during motion).

I use resizer for deinterlacing with this input parameters:

input.image_width = 720;
input.image_height = 576 / 2;
input.line_length = Align(720, 32) * 4;

In one of replays you suggested to throw away one of the fields, to discard it. Do I need to rewrite my tvp5158 driver (demux part) to do this?

I am open for any other suggestion.

Gradimir.

Gradimir,

Your deinterlace method is roughly the same -- you just require more memory to hold the demuxed buffer than you would if you rewrote the demux routine.  You also require more memory bandwidth, something that the DM365 seems to be in short supply of, because you are passing the both fields through EDMA when only one is needed.

You might want to try saving five or ten frames, raw, and displaying the 420 uyvy data in a third party program, to determine if the data coming out of the TVP5158 looks good.

-M

I will do this. Also will try to see how demuxing is implemented in tvp5158 driver, just to check if I am getting frames in right order.

I am expecting new board with dm368 processor and will try my application with the new board.

One more question I am using tvp5158 patch v02_01_27. Do I need to use some newer one?

Gradimir.

Gradimir,

So far, I've only used DM365.  I'm somewhat concerned with the DM368 and the second SD card, since achieving maximum clock rate will put the second SD clock above the maximum clock rate specified for that peripheral.  It would be a shame if the DM368 effectively disables the second SDIO port because they happen to share a clock.

As for the "patch", I used the latest one available.  I ended up rewriting the majority of the code, though, to squeeze as much as possible out of the DM365. 

-M

I tried to record couple of raw PAL frames, without processing through resizer or encoder. Frames that come out from tvp5158 do not look good. I cannot tell if the frames are out of order. For example when I move my hand over camera sometimes I can see it double on the frame, sometimes I can see two different parts of my hand in one frame.

Do you have maybe suggestion what I can try or do next?

Gradimir.

Gradimir,

Since you have checked the register and it seems correct, the only other thing that I can think of checking is to make sure that your cameras are, in fact, PAL.

-M

On all 4 cameras that I have been using there is a PAL mark. I do not have any other way to check if these cameras output video signal in PAL format.

Can hardware problem or other settings in video drive be the cause of this behavior? I have my own dm365 development board connected to Texas Instruments  tvp5158 evaluation module with flat cable that is not to short. I created my own list of command line options and have used some patched files for video front end driver.

Gradimir.

My last suggestion would be to save three consecutive super-frames and decode them on a PC manually (write a program to do so).  It will give you a better understanding of the demuxer and you can verify that the data coming from the TVP5158 is correct and that the problem lies elsewhere.

I do recall having to change something in the vpfe kernel driver, in dm365_ccdc.c, in the  ccdc_setwin function.  I had to set the vert_start to 0 instead of +1.