Problems outputting NTSC digital video on DM355

I imagine you are using two different configurations on the DM643x end, one for the NTSC case and one for the PAL case?

That neon green and pink image output is an artifact of having the video data offset by a byte causing chroma/luma swapping, so you may be able to get your colors right by adjusting the CCDCFG.Y8POS bit on the DM643x, or by adjusting the ordering coming out of the DM355.

The image being cut in the middle would most likely be a format register setting, you may want to try adjusting the image formatting registers like NPH, SPH, NLV, SLV, PPLN, etc on the DM643x to see how they impact the image being cut in half.

Bernie Thompson said:

I imagine you are using two different configurations on the DM643x end, one for the NTSC case and one for the PAL case?

Yes, that's the situation, although I'm using some code which wasn't programmed by me, so I'm not sure if I'm controlling all the details. I think so, but I'm not completely sure.

Bernie Thompson said:

That neon green and pink image output is an artifact of having the video data offset by a byte causing chroma/luma swapping, so you may be able to get your colors right by adjusting the CCDCFG.Y8POS bit on the DM643x, or by adjusting the ordering coming out of the DM355.

Yes, you told me on another post when I saw it in other tests. But the "funny" thing is that I've already tried changing the register you suggest (CCDCFG) and another one too (PCR). Both of them allow me to modify the YCbCr order, but yet I cannot see any difference in the resulting image: it's always the same. Isn't it strange? Anyway, I'm modifying them during runtime, by setting breakpoints. I don't think there's any problem doing it this way. Am I right? The VPFE configuration can be changed at any point, can't it?

Bernie Thompson said:

The image being cut in the middle would most likely be a format register setting, you may want to try adjusting the image formatting registers like NPH, SPH, NLV, SLV, PPLN, etc on the DM643x to see how they impact the image being cut in half.

I didn't know these ones. I'll have a look at them. At the beginning I was focusing on the colour issue but, as I've seen no difference in manipulating the registers, now I'm focusing on the cutting issue in case it's the reason for the colour issue.

Thank you very much Bernie!

I've got news. I've checked that video is coming half-cut from DM355. So it's normal that DM6435 sees the right half of the video frame as green , because DM355 is sending '0' for all luminance and chrominance signals, which I think means green in YCbCr.

But what's the reason for the DM355 cutting of the image? The only thing I change to switch from PAL to NTSC is the mode_idx field in the structure passed to the driver in the FBIO_QUERY_TIMING function call. And also the size of the video from 720x576 (PAL) to 720x480 (NTSC). What's wrong?

Please, I still need help!

Does anybody know which parameters should I configure in the FBIO_QUERY_TIMING driver call for the NTSC format? Might it be a matter of margins or sync lengths? It's the only difference between PAL and NTSC, and PAL works perfectly.

What version of the DM355 DVSDK software are you using (I believe FBIO_QUERY_TIMING is rather old)? In the current PSP 2.x there are simple sysfs entries to change between NTSC and PAL, though they primarily apply to the analog outputs out of the box they should work similarly with digital output enabled.

Even if I set the driver to output the colorbar, it comes cut through the digital video pins. But what surprises me is that the video is perfect in the analog video pins. Shouldn't it be exactly the same in both outputs? What's happening?

Thanks in advance!

Bernie Thompson said:

What version of the DM355 DVSDK software are you using (I believe FBIO_QUERY_TIMING is rather old)? In the current PSP 2.x there are simple sysfs entries to change between NTSC and PAL, though they primarily apply to the analog outputs out of the box they should work similarly with digital output enabled.

Sorry, I hand't seen your post. It's the DVSDK_1_30_00_40 version, which has the PSP_01_20_00_014 version. I'll have a look at the sysfs entries but I think I'm not used to them. Could you please explain me how to manage them?

R&D said:

Even if I set the driver to output the colorbar, it comes cut through the digital video pins. But what surprises me is that the video is perfect in the analog video pins. Shouldn't it be exactly the same in both outputs?

This is interesting, since you have only one set of timing parameters available the digital and analog outputs should be outputting the same content. Have you taken a look at the digital output with a logic analyzer to verify you are outputting the 'cut' half lines of data from the DM355?

Bernie Thompson said:

This is interesting, since you have only one set of timing parameters available the digital and analog outputs should be outputting the same content. Have you taken a look at the digital output with a logic analyzer to verify you are outputting the 'cut' half lines of data from the DM355?

Yes, that's the way I made sure of the situation. I checked the digital output with a logic analyzer and to my surprise I found out that the video was half-cut. In each line (I can see the different lines thanks to the hsync signal) I only have video in more or less the first half of it. The other half line is "0", which is consistent with what I see in my application: the right half of the image is green ("0" luminance and chrominance values). But if I switch to PAL, I can see the whole line with video information.

In both cases, PAL and NTSC, the rest of values and lengths (hsync, pixel clk, etc.) are exactly the same. The only difference is the "dissappeared" half line in NTSC. Isn't it strange?

I wonder if this is a progressive versus interlaced issue.  If progressive is expected, but only interlaced available (480i for NTSC), then you will likely only see half the screen.

Juan Gonzales said:

I wonder if this is a progressive versus interlaced issue.  If progressive is expected, but only interlaced available (480i for NTSC), then you will likely only see half the screen.

But in that case I think I would see the video cut horizontally, not vertically. Because I would be taking each field of the interlaced video as a whole frame. Am I correct?

What still surprises me a lot is to not see the same video in the analog and in the digital output...

R&D said:

But in that case I think I would see the video cut horizontally, not vertically. Because I would be taking each field of the interlaced video as a whole frame. Am I correct?

correct, sorry I missed the fact that the issue was on the vertical direction.

Let me see, you only have one corresponding set of registers defining the video window size for each of the active windows, and you only have on timing generator providing timing for both analog and digita video outputs.  So we can conclude all the video data is present in the OSD internal buffers because we can see it on the analog output, we can also conclude that the timing is probrably correct because we also see video displayed correctly on the analog output.  Please correct me if I am wrong in this assesment so far.

If so, the problem is likely in the DM355 registers specifically controlling DIGITAL video output port.  You mentioned in an earlier post you were observing 0's for chrominance, but luminance was ok.  This lead me to think that the digital video port may be programmed incorrectly for you specific hardware connection.  For example, if your hardware connection between DM355 and DM6437 is expecting to use 16-bit data bus but DM355 digital video port was configured to output 8-bit video data, then you can get zeros on the chroma pins.  I am not sure what the FBIO ioctl request is doing (is it actually programing 720x480 16-bit digital video output with discrete sync signals on hsync, vsync pins OR is it programming 8-bit BT.656 output with embedded syncs in data lines.  I believe hardware must be in BT656 standard mode for both analog and digital outputs to work correctly at the same time. 

If you can describe your hardware connection between DM355 and DM367 and check the sync signal ins digital video interface to determine if they are active or not, this should give us more information to narrow down the issue.

Juan Gonzales said:

Let me see, you only have one corresponding set of registers defining the video window size for each of the active windows, and you only have on timing generator providing timing for both analog and digita video outputs.  So we can conclude all the video data is present in the OSD internal buffers because we can see it on the analog output, we can also conclude that the timing is probrably correct because we also see video displayed correctly on the analog output.  Please correct me if I am wrong in this assesment so far.

You are right.

Juan Gonzales said:

If so, the problem is likely in the DM355 registers specifically controlling DIGITAL video output port.  You mentioned in an earlier post you were observing 0's for chrominance, but luminance was ok.

Not exactly. I've checked that for the right half of the image the value for both chrominances and luminance is '0', which means 'green' video.

Juan Gonzales said:

This lead me to think that the digital video port may be programmed incorrectly for you specific hardware connection.  For example, if your hardware connection between DM355 and DM6437 is expecting to use 16-bit data bus but DM355 digital video port was configured to output 8-bit video data, then you can get zeros on the chroma pins.  I am not sure what the FBIO ioctl request is doing (is it actually programing 720x480 16-bit digital video output with discrete sync signals on hsync, vsync pins OR is it programming 8-bit BT.656 output with embedded syncs in data lines.  I believe hardware must be in BT656 standard mode for both analog and digital outputs to work correctly at the same time.

Hardware is programmed to be in BT656 standard mode for both video outputs. Besides, it works perfectly for PAL. It only goes wrong when changing to NTSC.

Juan Gonzales said:

If you can describe your hardware connection between DM355 and DM367 and check the sync signal ins digital video interface to determine if they are active or not, this should give us more information to narrow down the issue.

How deep do you want me to describe the hardware? I mean, I can tell you that DM355 VPBE YOUTn pins are directly connected to DM6435 VPFE YIn (CCDn) pins. Both syncs, horizontal and vertical, as well as pixel clock are directly connected too. Is there anything else you consider interesting? Just ask me and I will tell you.

And thank you very much!

After some days off, here I am again. I've checked the sync lines in the digital video interface. Switching from PAL to NTSC looks good because it means a change in the VSYNC signal from a period of about 20ms for PAL (50 fields per second = 25 frames per second) to a period of about 16.6ms for NTSC (60 fields per second = 30 frames per second). But still the resulting image is like the picture in my first post when in NTSC mode. Any ideas?