Video input V4L2 pixel format selection

Thanks Jun. I chose something different which maybe is why it isn't working. I'll try what you suggested and report back.

Incidentally, do you have capture working and if so which demo have you found best to work with?

Ralph

Thanks Jun, I'll have a look but I also hope TI will answer too.

Ralph

Hi, I am currently busy with some other activity. I will reply in a day or two.

Regards,

Hardik Shah

For now until I look into the V4L2 documentation I am unsure what v4l2_mbus_pixelcode does.

I have things on the way to working now that I have worked out that I need to set all the fields of hdvpss_capture_sdev_info in ti81xx_vpss.c appropriately.

It seems that v4l2_mbus_pixelcode doesn't matter too much for me at this moment in time.

Many thanks to Jun for the heads up on the pixel formats.

I am now capturing the attached 1080p60 image using saLoopBackFbdev:

The image I am trying to capture is offset and the red and blue channels are swapped. I have tried playing with every setting there is in "static struct ti81xxvin_subdev_info hdvpss_capture_sdev_info" but I still can't get the capture working correctly.

Do you have any suggestions what I must do to capture the image correctly?

Thanks,

Ralph

We have checked that our red, blue and green channels are connected up correctly. I think the issue is to do with capturing the Linux framebuffer. Even when I do not have my video input I can still only capture an image with R and B transposed.

I have tweaked some settings and am now getting the following image. Notice the vertical purple line of single pixels that precedes the color bar patterns. You can't really see it but there is also a 1 pixel "blur" between each stripe of colour.

This should not be here. There should be only a 1 pixel black border around the colour bar image and the colour bars should be distinct and not blurred together at the edges.

Any idea what is causing this? Is it because of some internal colourspace conversion of the DM8168 from RGB to YUV and back again?

Thanks,

Ralph

Hi Ralph,

You are not the only one has R and B swaped issue.

When I was trying capture RGB, using saLoopFbdev code, I met the same problem.

 And I am also sure our hardware connection is okay.

What changes did you make to get at least right R and B?

Regards,

Jun

Hi Jun, it's good to know it isn't just me. I have found that my framebuffer RGB is correct however that is completely separate from the issue of captured video having R and B channels swapped.

To correct the captured raw RGB data, I imported it into GIMP image editor as a "raw" image of dimension 1920x1080. Then once imported you can use Colors->Components->Channel mixer to specify how to swap around the colours.

Ralph

Hi Ralph,

Thanks for your info. I see what you did. I though you have a way to set the firmware of DM8148 to capture correct image.

 I also used a software vooya to replay the captured raw data.

If choosing format as BGR interleave 444, the images seems to be okay, altough what I am expecting is RGB444 Planar.

Maybe at this point, TI expert really should clarify for us how come the R and B get swaped.

Regards,

Jun

Hi Jun,

If I try to set the format as BGR in ti81xx_vpss.c I get this error:

VIDIOC_STREAMON
: Invalid argument
Error in starting capture

Ralph

Hi Ralph,

sorry for misunderstanding.

I was saying set the color format in vooya.

So far there is no way for me to get right RGB raw data from DM81x v4l2 capture.

Regards,

Jun

Oops, I see now that Vooya is an image processing app like GIMP.

Ralph

Hi,

RGB planar is not possible.  RGB interleaved is only possible. RGB in memory arranged as B(LSB) G and R(MSB).

Regards,

Hardik Shah