video: stm32: dcmipp: addition of (semi)planar format support #94081

avolmat-st · 2025-08-04T13:30:30Z

The STM32 DCMIPP pipe 1 (main) is able to generate semi planar and planar formats such as NV12/NV16 or YUV420.
This PR adds definition of those formats as well as their description in the API header and add their support within the dcmipp driver.

avolmat-st · 2025-08-07T10:07:10Z

Added NV24/NV42 as well

avolmat-st · 2025-08-12T08:50:38Z

Mark the PR as Ready for review now that I have validated all 6 formats the DCMIPP can output (NV12/NV21/NV16/NV61/YUV420/YVU420)

hfruchet-st · 2025-08-13T14:56:10Z

Tested OK on N6 for NV12 with #92884

ngphibang

LGTM, just a minor comment on format documentation

ngphibang · 2025-08-14T08:05:19Z

include/zephyr/drivers/video.h

+/**
+ * CbCr(UV) plane has same width and height as Y plane
+ *
+ * @code{.unparsed}
+ * | Yyyyyyyy Yyyyyyyy | Yyyyyyyy Yyyyyyyy |
+ * | Yyyyyyyy Yyyyyyyy | Yyyyyyyy Yyyyyyyy |
+ * | ... |
+ * | Uuuuuuuu Vvvvvvvv | Uuuuuuuu Vvvvvvvv |
+ * | Uuuuuuuu Vvvvvvvv | Uuuuuuuu Vvvvvvvv |
+ * | ... |
+ * @endcode
+ */


Documentation is the same for NV16 and NV24. Should we add something to distinguish them ?
Idem for NV61 and NV42

Indeed. Probably the way they are all represented is not the best one. Since everything is 8bits, there is no need to have Yyyyyyyy so just mentioning 8bit for each sample in the description and then adding number behind each component to indicate to which pixel it correspond could be better.

Something like:

| Y0 Y1 Y2 Y3| | Y.. Y.. Y.. Y..| | U0 V0 U1 V1 U2 V2 U3 V3 | | U.. V.. U.. V.. U.. V.. U.. V.. |

Yes, something like what is described by Microsoft : https://learn.microsoft.com/en-us/windows/win32/medfound/recommended-8-bit-yuv-formats-for-video-rendering

josuah

Nice to see this coming.
A few suggestions for how to improve it just a bit, though all can be done in the future as well.

josuah · 2025-08-13T20:11:25Z

drivers/video/video_stm32_dcmipp.c

+	/* TODO - the HAL is missing a SetMemoryAddress for auxiliary addresses */
+	/* Update main buffer address */
+	if (pipe->id == DCMIPP_PIPE0) {
+		WRITE_REG(dcmipp->hdcmipp.Instance->P0PPM0AR1, (uint32_t)plane);


There is also sys_write32() available, which requires #include <zephyr/sys/sys_io.h> if interested.

josuah · 2025-08-13T22:12:43Z

drivers/video/video_stm32_dcmipp.c

+		if (fmt->pixelformat == VIDEO_PIX_FMT_NV12 ||
+		    fmt->pixelformat == VIDEO_PIX_FMT_NV21 ||
+		    fmt->pixelformat == VIDEO_PIX_FMT_NV16 ||
+		    fmt->pixelformat == VIDEO_PIX_FMT_NV61 ||
+		    fmt->pixelformat == VIDEO_PIX_FMT_YUV420 ||
+		    fmt->pixelformat == VIDEO_PIX_FMT_YVU420) {


Would it be useful to wrap this in a macro? For instance one locally defined in this driver, some VIDEO_IS_PLANAR(fmt->pixelformat) for instance.

josuah · 2025-08-13T22:16:14Z

drivers/video/video_stm32_dcmipp.c

+		if (fmt->pixelformat == VIDEO_PIX_FMT_NV12 ||
+		    fmt->pixelformat == VIDEO_PIX_FMT_NV21 ||
+		    fmt->pixelformat == VIDEO_PIX_FMT_NV16 ||
+		    fmt->pixelformat == VIDEO_PIX_FMT_NV61 ||
+		    fmt->pixelformat == VIDEO_PIX_FMT_YUV420 ||
+		    fmt->pixelformat == VIDEO_PIX_FMT_YVU420) {
+			pipe_cfg.PixelPipePitch = fmt->width;


If I understood, bere this means that fmt->width is being used as pitch for the first plane.

This seems to work for the particular formats used here, but if using a macro VIDEO_IS_PLANAR(), maybe this would also need a macro a bit like this maybe:

#define VIDEO_Y_PLANE_PITCH(fmt) (VIDEO_IS_PLANAR((fmt)->pixelformat) ? (fmt)->width : 0)

josuah · 2025-08-13T22:20:42Z

drivers/video/video_stm32_dcmipp.c

+
+#if defined(STM32_DCMIPP_HAS_PIXEL_PIPES)
+	if (fmt->pixelformat == VIDEO_PIX_FMT_YUV420 || fmt->pixelformat == VIDEO_PIX_FMT_YVU420) {
+		uint8_t *u_addr = pipe->next->buffer + fmt->width * fmt->height;


It can be difficult to guess that fmt->width is actually the pitch of the Y plane.
How about a macro like this:

#define VIDEO_Y_PLANE_SIZE(fmt) (VIDEO_Y_PLANE_PITCH(fmt) * (fmt)->height)

The Y plane is present in all YUV planar formats so hopefully quite generic.

josuah · 2025-08-14T10:01:38Z

include/zephyr/drivers/video.h

+ * @code{.unparsed}
+ * | Yyyyyyyy Yyyyyyyy | Yyyyyyyy Yyyyyyyy |
+ * | Yyyyyyyy Yyyyyyyy | Yyyyyyyy Yyyyyyyy |
+ * | ... |
+ * | Uuuuuuuu Vvvvvvvv | Uuuuuuuu Vvvvvvvv |
+ * | Uuuuuuuu Vvvvvvvv | Uuuuuuuu Vvvvvvvv |
+ * | ... |
+ * @endcode


If wanting a fully expanded version, how about something like this?

/** * The CbCr (UV) plane has the same width and height as the Y plane. * * Where each letter (A, B, C...) below represents a logical group of pixels: * * @code{.unparsed} * A A B B * | Yyyyyyyy | Yyyyyyyy | Yyyyyyyy | Yyyyyyyy | ... * A A B B * | Yyyyyyyy | Yyyyyyyy | Yyyyyyyy | Yyyyyyyy | ... * C C D D * | Yyyyyyyy | Yyyyyyyy | Yyyyyyyy | Yyyyyyyy | ... * C C D D * | Yyyyyyyy | Yyyyyyyy | Yyyyyyyy | Yyyyyyyy | ... * * | ... | * * A A B B * | Uuuuuuuu Vvvvvvvv | Uuuuuuuu Vvvvvvvv | ... * C C D D * | Uuuuuuuu Vvvvvvvv | Uuuuuuuu Vvvvvvvv | ... * * | ... | * @endcode */

I originally wouldn't put the pixel packing description but it turns out that there are as well 10bit, 12bit variants for those formats, so, yes, ok to keep the pixel packing part.

Also having the following diagram which show how Y / U / V map together is nice:

Y0 Y1 Y2 Y3 ...

Y6 Y7 Y8 Y9 ...

...

U0/1/6/7 V0/1/6/7 U2/3/8/9 V2/3/8/9 ...

...

Let me prepare the updated descriptions with that

josuah · 2025-08-14T10:02:36Z

include/zephyr/drivers/video.h

+/**
+ * CrCb(VU) plane has same width as Y plane however half height
+ *
+ * @code{.unparsed}
+ * | Yyyyyyyy Yyyyyyyy | Yyyyyyyy Yyyyyyyy |
+ * | Yyyyyyyy Yyyyyyyy | Yyyyyyyy Yyyyyyyy |
+ * | ... |
+ * | Vvvvvvvv Uuuuuuuu | Vvvvvvvv Uuuuuuuu |
+ * | Vvvvvvvv Uuuuuuuu | Vvvvvvvv Uuuuuuuu |
+ * | ... |
+ * @endcode
+ */


Related to the discussion above:

/** * The CrCb (VU) plane has same width and height as the Y plane * * Where each letter (A, B, C...) below represents a logical group of pixels: * * @code{.unparsed} * A A B B * | Yyyyyyyy | Yyyyyyyy | Yyyyyyyy | Yyyyyyyy | ... * A A B B * | Yyyyyyyy | Yyyyyyyy | Yyyyyyyy | Yyyyyyyy | ... * C C D D * | Yyyyyyyy | Yyyyyyyy | Yyyyyyyy | Yyyyyyyy | ... * C C D D * | Yyyyyyyy | Yyyyyyyy | Yyyyyyyy | Yyyyyyyy | ... * * | ... | * * A A B B * | Vvvvvvvv Uuuuuuuu | Vvvvvvvv Uuuuuuuu | ... * C C D D * | Vvvvvvvv Uuuuuuuu | Vvvvvvvv Uuuuuuuu | ... * * | ... | * @endcode */

josuah · 2025-08-14T10:07:49Z

include/zephyr/drivers/video.h

+ * CbCr(UV) plane has same width and height as Y plane
+ *
+ * @code{.unparsed}
+ * | Yyyyyyyy Yyyyyyyy | Yyyyyyyy Yyyyyyyy |
+ * | Yyyyyyyy Yyyyyyyy | Yyyyyyyy Yyyyyyyy |
+ * | ... |
+ * | Uuuuuuuu Vvvvvvvv | Uuuuuuuu Vvvvvvvv |
+ * | Uuuuuuuu Vvvvvvvv | Uuuuuuuu Vvvvvvvv |
+ * | ... |
+ * @endcode


Related to the discussion above:

/** * The CrCb (VU) plane has same width and height as the Y plane * * Where each number below represents a logical group of pixels: * * @code{.unparsed} * A A B B * | Yyyyyyyy | Yyyyyyyy | Yyyyyyyy | Yyyyyyyy | ... * C C D D * | Yyyyyyyy | Yyyyyyyy | Yyyyyyyy | Yyyyyyyy | ... * E E F F * | Yyyyyyyy | Yyyyyyyy | Yyyyyyyy | Yyyyyyyy | ... * G G H H * | Yyyyyyyy | Yyyyyyyy | Yyyyyyyy | Yyyyyyyy | ... * * | ... | * * A A B B * | Uuuuuuuu Vvvvvvvv | Uuuuuuuu Vvvvvvvv | ... * C C D D * | Uuuuuuuu Vvvvvvvv | Uuuuuuuu Vvvvvvvv | ... * E E F F * | Uuuuuuuu Vvvvvvvv | Uuuuuuuu Vvvvvvvv | ... * G G H H * | Uuuuuuuu Vvvvvvvv | Uuuuuuuu Vvvvvvvv | ... * * | ... | * @endcode */

josuah · 2025-08-14T10:09:37Z

include/zephyr/drivers/video.h

+ * @code{.unparsed}
+ * | Yyyyyyyy Yyyyyyyy | Yyyyyyyy Yyyyyyyy |
+ * | Yyyyyyyy Yyyyyyyy | Yyyyyyyy Yyyyyyyy |
+ * | ... |
+ * | Vvvvvvvv Uuuuuuuu | Vvvvvvvv Uuuuuuuu |
+ * | Vvvvvvvv Uuuuuuuu | Vvvvvvvv Uuuuuuuu |
+ * | ... |
+ * @endcode


/** * The CrCb (VU) plane has same width and height as the Y plane * * Where each number below represents a logical group of pixels: * * @code{.unparsed} * A A B B * | Yyyyyyyy | Yyyyyyyy | Yyyyyyyy | Yyyyyyyy | ... * C C D D * | Yyyyyyyy | Yyyyyyyy | Yyyyyyyy | Yyyyyyyy | ... * E E F F * | Yyyyyyyy | Yyyyyyyy | Yyyyyyyy | Yyyyyyyy | ... * G G H H * | Yyyyyyyy | Yyyyyyyy | Yyyyyyyy | Yyyyyyyy | ... * * | ... | * * A A B B * | Vvvvvvvv Uuuuuuuu | Vvvvvvvv Uuuuuuuu | ... * C C D D * | Vvvvvvvv Uuuuuuuu | Vvvvvvvv Uuuuuuuu | ... * E E F F * | Vvvvvvvv Uuuuuuuu | Vvvvvvvv Uuuuuuuu | ... * G G H H * | Vvvvvvvv Uuuuuuuu | Vvvvvvvv Uuuuuuuu | ... * * | ... | * @endcode */

Add description and fourcc define for some of the 2 and 3 planes pixel formats. Signed-off-by: Alain Volmat <[email protected]>

ISP is part of the pixel pipes hence it doesn't make any sense to try to call ISP external handlers if the DCMIPP doesn't have pixel pipes available. Signed-off-by: Alain Volmat <[email protected]>

Add support for NV12/NV21, NV16/NV61 and YUV420/YVU420 (semi)planar formats which can be output by the main zephyrproject-rtos#1 pipe. Signed-off-by: Alain Volmat <[email protected]>

avolmat-st · 2025-08-14T13:59:53Z

@ngphibang @josuah , I've only updated the video.h header with the formats description for now.

sonarqubecloud · 2025-08-14T14:25:29Z

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

avolmat-st mentioned this pull request Aug 5, 2025

video: introduction of STM32 VENC driver for H264 hardware video compression #92884

Draft

avolmat-st force-pushed the pr-dcmipp-planar-addition branch 2 times, most recently from 80c3b9c to 0108872 Compare August 7, 2025 10:06

avolmat-st marked this pull request as ready for review August 12, 2025 08:50

zephyrbot added platform: STM32 ST Micro STM32 area: Video Video subsystem labels Aug 12, 2025

zephyrbot requested review from djiatsaf-st, erwango, etienne-lms, FRASTM, gautierg-st, GeorgeCGV, josuah, loicpoulain, marwaiehm-st, mathieuchopstm and ngphibang August 12, 2025 08:51

zephyrbot assigned josuah and ngphibang Aug 12, 2025

ngphibang reviewed Aug 14, 2025

View reviewed changes

ngphibang mentioned this pull request Aug 14, 2025

video: fix dcmipp devicetree #94400

Open

josuah reviewed Aug 14, 2025

View reviewed changes

video: add planar formats (NV12/NV21/NV16/NV61/NV24/NV42/YUV420/YVU420)

d516740

Add description and fourcc define for some of the 2 and 3 planes pixel formats. Signed-off-by: Alain Volmat <[email protected]>

Alain Volmat added 2 commits August 14, 2025 15:57

video: stm32: dcmipp: make isp handling depends on pixel pipes

f20bf99

ISP is part of the pixel pipes hence it doesn't make any sense to try to call ISP external handlers if the DCMIPP doesn't have pixel pipes available. Signed-off-by: Alain Volmat <[email protected]>

video: stm32: dcmipp: add (semi)planar support

85c17b2

Add support for NV12/NV21, NV16/NV61 and YUV420/YVU420 (semi)planar formats which can be output by the main zephyrproject-rtos#1 pipe. Signed-off-by: Alain Volmat <[email protected]>

avolmat-st force-pushed the pr-dcmipp-planar-addition branch from 0108872 to 85c17b2 Compare August 14, 2025 13:58

avolmat-st mentioned this pull request Aug 15, 2025

Allow STM32 DCMIPP to work with UVC sample #94562

Draft

video: stm32: dcmipp: addition of (semi)planar format support #94081

Are you sure you want to change the base?

video: stm32: dcmipp: addition of (semi)planar format support #94081

Conversation

avolmat-st commented Aug 4, 2025

Uh oh!

avolmat-st commented Aug 7, 2025

Uh oh!

avolmat-st commented Aug 12, 2025

Uh oh!

hfruchet-st commented Aug 13, 2025

Uh oh!

ngphibang left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

josuah left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

josuah Aug 14, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

josuah Aug 14, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

josuah Aug 14, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

josuah Aug 14, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

josuah Aug 14, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

avolmat-st commented Aug 14, 2025

Uh oh!

sonarqubecloud bot commented Aug 14, 2025

Quality Gate passed

Uh oh!

Uh oh!

josuah Aug 14, 2025 •

edited

Loading

josuah Aug 14, 2025 •

edited

Loading

josuah Aug 14, 2025 •

edited

Loading

josuah Aug 14, 2025 •

edited

Loading

josuah Aug 14, 2025 •

edited

Loading