Experimental support for the NV12 pixel format

[dkogan]

Hi. This patch adds support for NV12. This has some issues, and isn't ready to merge as is.

I don't have genicam hardware that produces this pixel format, but I do have such a v4l2 stream (via v4l2loopback) that this patch enables. Concerns:

• The value of ARV_PIXEL_FORMAT_NV12 is made up. I don't entirely understand where this is supposed to come from, and the 5555 part is arbitrary
• arvv4l2stream.c was assuming that an image is made up of rows with bytes_per_line_data each, and the whole thing has payload_size * bytes_per_line_data bytes. This isn't true for NV12. It has bytes_per_line = width and payload_size = widthheight1.5 and bytes_per_line_data isn't well-defined. Can we simply remove bytes_per_line_data and the logic that uses it?

Thanks

[EmmanuelP]

Hi Dima,

Genicam pixel format values are described here:

https://www.emva.org/wp-content/uploads/GenICamPixelFormatValues.pdf
https://www.emva.org/wp-content/uploads/GenICam_PFNC_2_4.pdf

NV12 would be:

YCbCr420_8_YY_CbCr_Semiplanar 0x020C0112 PFNC YCbCr 4:2:0 8-bit YY/CbCr Semiplanar

Can we simply remove bytes_per_line_data and the logic that uses it?

I don't think so. It looks like we need to know whether it is a semiplanar format, but I don't know how.

[EmmanuelP]

Can we simply remove bytes_per_line_data and the logic that uses it?

I don't think so. It looks like we need to know whether it is a semiplanar format, but I don't know how.

After more reading, it seems a full handling of NV12 would be to use the v4l2 multiplanar API and store the data in a MULTIPART aravis buffer, but it is not trivial. You need to modify how arvv4l2device handles pixel formats, and also make arvviewer multipart aware.

A less complete solution would be to move the computation of x_padding to arv_v4l2_device_get_image_format. Here you may be able to detect if the format is semiplanar, and store the result in a regular aravis buffer if the x_padding of the Y plane and the one of the UV plane is the same.

[dkogan]

The code in this PR works great for my single use case. Am I just getting lucky with my data layout matching some simple assumptions?

[EmmanuelP]

The code in this PR works great for my single use case. Am I just getting lucky with my data layout matching some simple assumptions?

Not lucky, because probably for most of the devices bytes_per_line is equal to bytes_per_pixel * image_width. But I guess it is not always the case, not guaranteed. Similarly, payload_size is not always bytes_per_line * image_height. It depends on hardware constraints.