TVP7002/DM8168 wrong color space

I am not sure what you mean by "R=128, G=255, B=128"?

Do you mean that you need to set the analog inputs to the TVP7002 such that the digital outputs of the TVP7002 are R=128, G=255, B=128 in order to get a white display on the DM8168? If so, then you are configured for YCbCr inputs and not RGB.

The RGB values you note are what you would expect when configured for YCbCr so I think you have an incorrect color space specified somewhere in the processing path.

If so, then the issue is a DM capture port configuration.

Regarding TVP7002 configuration, check the example setup files available on the TVP7002 EVM web page. There are setups for many different configurations. Pick the one appropriate for your desired input to output conversion.

http://www.ti.com/tool/tvp7002evm

Specifically TVP7002 + THS8200 EVM Kit Setup (Rev. A)

BR,

Steve

Steve,

Thx for your feedback.

We are using a PC to generate the VGA signal. We can adjust any color based on the digital RGB values displayed on the PC. The VGA signal is sent to the the DM8168 custom board.

We are setting inside the PC a screen with a color R=128, G=255, and B=128. And through the chain TVP7002 + DM8168 + TVP7002 linux driver + V4L2 + gstreamer, we are seeing white...

We configured to RGB input and the TVP7002 behaves as if we were having YCbCr input.

We have configured register 0x18 to have value 0x11. And tried also default configuration (0x01) and other values. None have any effect. We also tried to adjust the color space matrix. No effect.

Why would any change in color space coefficients have no effect?

Is the color matrix really used? Is their any hidden bit or register that would prohibit the use of the color space matrix other than the register 18 bit 3?

We are going to investigate the DM8168 side.

Thank you

Karim

You need to start at one end of the signal processing chain and check each step output to make sure it is as expected.

Start off by looking at the TVP7007 digital outputs to make sure that they are correct (assuming you have already checked the register settings against the settings I previously pointed you to).

With an oscilloscope look at the MSB of each of red, green & blue to make sure that when you output a white display that the MSBs are high for the entire active line period and low when displaying black. If there is a lot of toggling or they are not in the correct state then the TVP is likely not configured correctly.

If the TVP outputs are correct then move to the capture buffer and examine it to make sure the VIP is configured correctly.

Continue up the processing path. At some point you will find which step is configured incorrectly.

There are no hidden registers but the CSC needs to be both enabled and configured. Please check register settings as per the example settings previously mentioned.

BR,

Steve

Steve,

Thx for your feeback.

With a component input, we are getting good signals up to the gstreamer. Video looks good.

However, with VGA, the picture is pink.

We are in the process of checking the 16 digital line out of the TVP7002 (Y  and CbCr) with the VGA input.

Best,

KB

If it is good with component then the TVP must be configured for component. Make sure you re-configure correctly for RGB when you present an RGB input.

On a side note, outputting in 422 from the TVP when the input is RGB will smear the colors slightly. 422 is not very good for computer graphics.

BR,

Steve

Steve,

We checked the digital output from the TVP with different colors at the input signals.

The output seems good Y and CbCr... except for the white.

For white color, we should get Y signal high, and CbCr low. Y is high as expected.

However the MS bit of the CbCr stays high.

I am wondering if we have an offset issue somewhere when inputting VGA.

Any thought?

Thx

KB

All I can suggest is that you double/triple check the configuration against the example setup files available on the TVP7002 EVM web page.

I don't really understand how "The output seems good Y and CbCr... except for the white" White is not a special color. There is nothing that can ONLY affect white. What about not quite white (i.e. light gray) ?

If the digital output is in YUV mode then it is possible for the MSB of chroma to be high since the value may be very fractionally negative, hecen the MSB set. In YUV mode the chroma value is a signed number output.

BR,

Steve

Steve,

Thank you for your feedback.

We fixed the issue.

The TVP7002 driver under Linux is overwriting registers during run-time... That was turning off the color space.

Now we are getting video with the VGA input through Linux drivers and gstreamer.

One question:  the picture is a little bit fuzzy when we display small texts.

Do the color space transformation or/and the under-sampling for Cb/Cr create this fuzziness? Or could it be anything else?

Looks like there is small average between pixel.

Best,

Karim

Glad you found the issue.

Regarding the color smearing, as I mentioned previously... "On a side note, outputting in 422 from the TVP when the input is RGB will smear the colors slightly. 422 is not very good for computer graphics."

Yes, this is cause by down sampling the color from 444 to 422. It is decimating the color information, throwing away every other color sample so will appear like averaging.

This is usually OK for video applications but computer graphics will suffer.

BR,

Steve

Hi Karim,  

   I'm also trying to get the vga input working on the tvp7002 with the dm8168. We already did the changes on the 7002 driver using the recommended configuration for embedded sync signals and we changed the v4l2 driver to be able to receive 1024x768 buffers since that is the resolution given by my laptop. However, gstreamer can't capture frames yet, testing with saloopback we are seeing the same problem, the application is not able to dequeue buffers and the VPSS registers doesn't report frames in the inputs. I will really appreciate your comments about:

1. Which resolutions are you using? Did you modify the V4L2 driver of the 8168? if so, which change you did?

2. Are you using embedded sync signals?

3. Could you share the configuration that you are using on the tvp7002?

Thanks for the help,

David

Hi David,

Typically VGA input is discrete sync input, not embedded sync input. So you will need to configure port in discrete sync mode.

Rgds,

Brijesh

David,

1/ we did not change V4L2 driver. We tested many standard resolutions. Did you look with an oscilloscope or digital analyzer the digital lines coming out from the TVP7002? Display a green image, then a red, then a blue to see what you are getting. Are you using 16-bit compressed data or 24-bit on the output of the TVP7002?

2/ We tested both with synch (with composite input) and without synch (with VGA signals). Without sync, look at the

3/ We used the standard settings provided by TI. They worked.

You can buy some converters that will take your laptop screen and convert to any resolution you need. They can be connected to the USB port. very convenient to change resolution.

I don't recall if 1024x768 is supported by the TVP7002 driver!

Make sure you are using the standard resolution that the driver support for now. Then if you need other resolution, you can probably add them to the TVP7002 driver. Make sure also gstreamer supports your resolution and color space.

I think gstreamer as is, does not support 24-bit color space...

Hope that helps.

Rgds

Karim

Hi Karim and Brijesh,

        Thanks for your help, some comments:

@Brijesh: VGA normally uses discrete sync so we are capturing discrete sync on the TVP7002 side but generating embedded sync signals from the TVP7002 to the VPSS. This should work right?

@Karim:

1) So you used the default configuration of the driver, this is interesting, we were trying the set of registers recommended by TI on the spreadsheet attached by Steve above, maybe they are just to work properly with the THS8200 and not with the VPSS. We will remove the changes and try again. We looked at the scope and the signals seems fine but I was not sure if we were setting the TRS in the right place. I will run the test that you suggested and let you know. We are using 16bits at the output of the TVP7002 but we can try 24 too. Did you use 24 at the end due color problems?

2) So with VGA you used discrete sync? did you try with embedded sync? Maybe that is the problem, we are trying to get it working with embedded sync signals and VGA.

3) Interesting. Thanks! We will try it.

We are not using a converted but I found that you can generate any VGA signal with your computer using xranr, for instance the one mentioned in the spreadsheet:

h backporch 220
h frontporch 110
v frontporch 5
v backporch 20

xrandr --newmode "1280x720_spreadsheet" 74.250 1280 1390 1430 1650 720 725 730 750 +hsync +vsync
xrandr --addmode VGA1 "1280x720_spreadsheet"
xrandr --output VGA1 --mode 1280x720_spreadsheet

If you want to use the VESA parameters you can run 

cvt 1280 720 

and get the values to use in your computer.

Yes, at this point we switched to 720p because is standard at the V4L2 driver of the DM816x, we are also using saloopback to make it simpler to finally move to gstreamer,

Thanks for your comments, I will let you know the results. We will try with the EVM too to discard a hw problem,

-David

It would be good to clarify some terminology since it is getting confusing.

In the analog domain the terms are SoG (sync on green) to mean that the sync signal is combined with the Y channel or green channel. The term separate syncs is used to indicate that there are individual 'analog' signals for H & V sync.

In the digital domain the term embedded syncs means that the start of active video and end of active video codes are embedded in the digital color data streams. Discrete syncs means there are individual digital signals for each of H, V and where necessary FID.

Analog VGA virtually NEVER uses SoG syncs anymore and pretty much is always separate syncs.

Analog YPbPr virtually ALWAYS uses SoG. I have never seen  separate syncs for YPbPr.

In the digital domain for video applications (i.e. YPbPr analog video) you should use digital YUV 422 output. Embedded syncs is easier and more common but discrete is OK too.

Digital VGA should ALWAYS be 24 bit discrete syncs. Using embedded syncs reduces the dynamic range. Using 16 bit 422 completely destroys color sharpness and converting from RGB to YUV kills color fidelity.

BR,

Steve

Steve,

I agree with you 100%. RGB to YUV really kills the color fidelity.

I am wondering why the EVM DM8168 from Spectrum does not have the 24-bit implemented in the drivers. The hardware is definitively capable of it. It is still a nice product.

We never found the source code modified by TI for v4l2. If you know were to find it, let me know.

The standard link to TI open source does not provide the v4l2 source used in the EVM.

Rgds

KB

Hi Steve and Karim,

    @Steve: Thanks for your comments, I should have added the correct description in my post. To be clear we were using VGA with discrete sync signals on the analog domain and trying to get 16bits with embedded sync signals out of the TVP7002 in the discrete domain. Using the EVM and adding some code to program the external chips we were able to capture 1080p and 720p from the VGA input. Now we are porting the changes to our hardware to see if we were having a hardware issue.

     @Karim: I think that capturing 24bits just requires a change in the ti81xx_vpss.c file, specifically in the lines:

.video_capture_mode =
VPS_CAPT_VIDEO_CAPTURE_MODE_SINGLE_CH_NON_MUX_EMBEDDED_SYNC,
.video_if_mode = VPS_CAPT_VIDEO_IF_MODE_16BIT,
.input_data_format = FVID2_DF_YUV422P,

Since in that case the TVP would give in the discrete domain 24bits RGB with discrete sync signals. Also I think that you can use saLoopBackFbdev for testing.

Now, what I am not sure is how to display that using the video pipelines since they require YUY2 and not RGB, in any case we would need a color space conversion and we would loose the color fidelity in any case right? The other option would be to use a framebuffer to display but I am not sure if we could get the desired framerate. Something similar happens if you want to encode that.

-David