PipeWire camera source: out.linesize[i] never set for planes > 0 — NV12 renders green

[EberhartLeberhart]

Operating System Info

Other

Other OS

Linux Mint 22 (Ubuntu 24.04 base)

OBS Studio Version

32.2.2

OBS Studio Version (Other)

No response

OBS Studio Log URL

https://obsproject.com/logs/L9kCrW6cSQPcC08g

OBS Studio Crash Log URL

No response

Expected Behavior

The camera preview shows the camera image with correct colours, as it does in every other consumer of the same PipeWire node (Firefox, GNOME Snapshot, cam, a gst-launch-1.0 pipewiresrc pipeline).

Current Behavior

The preview is unusable. It splits into three horizontal regions:

top: the scene, rendered entirely in green — the luma plane, correct
middle: a flat band containing a faint, half-resolution copy of the scene — this is the chroma plane being drawn as image data
bottom: noise that changes every frame — reads past the end of the valid data

The negotiated format is fine, and the stream reports streaming without error:

[pipewire] Negotiated format:
[pipewire] Format: 23 (Spa:Enum:VideoFormat:NV12)
[pipewire] Size: 640x480
[pipewire] Framerate: 30/1
[pipewire] Stream state: "streaming" (error: none)

Cause: in plugins/linux-pipewire/pipewire.c, prepare_obs_frame() sets only frame->linesize[0], and the loop in process_video_async() assigns out.data[i] for every plane but never out.linesize[i]. The frame is zero-initialised, so the chroma plane is handed to OBS with a stride of 0. Single-planar formats are unaffected; NV12 is not.

Steps to Reproduce

1. Use a camera that offers NV12 through PipeWire (here: OV8865 / OV5693 behind an Intel IPU3, via libcamera).

2. Add a "Video Capture Device (PipeWire)" source and select that camera.

3. Observe the preview.

For comparison, in the same OBS session: a USB camera delivering YUYV renders correctly. Converting the same IPU3 camera to a single-planar format and republishing it also renders correctly:

gst-launch-1.0 pipewiresrc target-object= !
video/x-raw,width=1280,height=720,framerate=30/1 !
videoconvert ! video/x-raw,format=YUY2 !
pipewiresink stream-properties="props,media.class=Video/Source,media.role=Camera,node.description=single-plane"

Same application, same camera, same path — only the plane count differs.

Anything else we should know?

The code

prepare_obs_frame():

c
frame->linesize[0] = SPA_ROUND_UP_N(frame->width * obs_pw_video_format.bpp, 4);

process_video_async():

c
for (uint32_t i = 0; i < buffer->n_datas && i < MAX_AV_PLANES; i++) {
out.data[i] = buffer->datas[i].data;
if (out.data[i] == NULL) { ... }
}

out.linesize[i] is never assigned. The DEBUG_PIPEWIRE block immediately below logs exactly that value, so a debug build should print Linesize:0 for plane 1.

Unchanged from 30.0.2 through current master.

Suggested fix
c
for (uint32_t i = 0; i < buffer->n_datas && i < MAX_AV_PLANES; i++) {
out.data[i] = buffer->datas[i].data;
if (out.data[i] == NULL) { ... }

    if (buffer->datas[i].chunk->stride > 0)
            out.linesize[i] = buffer->datas[i].chunk->stride;

}

Keeping the computed value as a fallback covers producers that leave stride at 0.

What was ruled out
Camera, driver, libcamera — cam --capture, GNOME Snapshot and Firefox render the same cameras correctly through the same stack. A 300-frame capture at 1280x720 has stable mean luminance and neutral RGB.
Resolution — 640x480 and 1280x720 both behave correctly in every other consumer.
Colorimetry — the negotiated format carries colorRange 16-235, colorMatrix bt601, transferFunction srgb, colorPrimaries bt709. Wrong colorimetry would shift colours, not produce a flat band plus a duplicate image below it.
Distribution or PipeWire version — same behaviour on Linux Mint 22 (PipeWire server 1.0.5, client library 1.4.9) and Fedora 44 (1.6.8), and with both the 32.2.2 Flatpak and the 30.2.3 distribution package.
Not verified

I have not tested the patch. My out-of-tree build of linux-pipewire.so fails format negotiation for unrelated reasons, so I did not want to present it as tested. The analysis rests on the observed behaviour and the source. Happy to test a patch on this hardware.

Possibly related
#10588 — NV12 cameras behaving inconsistently. Some reports there mention low framerate and low resolution, which may be something else entirely.
#10180 — a gstreamer-fed PipeWire node fails with no more input formats as soon as OBS connects. I hit this too while testing the workaround above, so it looks like an independent renegotiation problem.

[Fenrirthviti]

Why was this patch not tested?

[EberhartLeberhart]

I did try. I built linux-pipewire.so out of tree against the installed libobs 30.2.3 headers (plus glad.c, since the packaged plugin has no separate glad library). It loads, the camera source appears — but format negotiation fails with no more input formats before a single frame arrives, on a camera that works fine with the packaged plugin.

So my build does not even reproduce the working baseline, which makes it useless as a control: any difference after applying the patch would prove nothing. Rather than say "tested" on the back of that, I said what I actually knew.

I would like to finish it. If you can tell me what the packaged build sets that a plain gcc -shared against the same headers does not — or point me at the relevant CMake flags — I will build it properly and report back. I can also build all of OBS from source if that is the more reliable route; it just takes a while on this hardware.

The rest of the report stands on its own: the same camera through the same PipeWire path renders correctly in OBS when converted to a single-planar format, and out.linesize[i] is visibly never assigned in the loop.

[EberhartLeberhart]

Update on testing.

I built OBS from source to get a control I could trust. Full build of 30.2.3 succeeded, all plugins load, the PipeWire camera source appears.

It does not help, because 30.2.3 cannot stream these cameras at all — with or without the patch. With a fresh config directory and exactly one camera source, the single stream still dies during negotiation:

[camera-portal] streaming camera 'libcamera_input._SB.PCI0.I2C2.CAMF'
[pipewire] Created stream
[pipewire] Stream state: "connecting" → "paused"
[camera-portal] Updating pixel formats
[camera-portal] Selected format for '...CAMF'
[camera-portal] Updating device ...CAMF
[camera-portal] Selected format for '...CAMF'
[pipewire] Stream state: "error" (error: no more input formats)

The format-selected callback runs repeatedly while the stream is still negotiating. In 30.2.3 every one of those calls goes straight to stream_camera(). In 32.2.2 that path is guarded:

c
if (!camera_source->obs_pw_stream || camera_source->restart_stream ||
last_subtype != camera_source->subtype ||
last_format != camera_source->format.spa_format) {
camera_source->restart_stream = false;
stream_camera(camera_source);
} else if (camera_source->obs_pw_stream) {
obs_pipewire_stream_set_resolution(...);
}

So a build of 30.2.3 cannot reproduce the working baseline, which makes any before/after comparison meaningless. I did not want to present that as a test.

Next step is to build 32.2.2 instead and repeat it there. I will report back either way.

Possibly worth noting separately: on hardware with a single ISP path this makes the PipeWire camera source in 30.2.3 unusable, which may be the same thing as #10180.

[EberhartLeberhart]

Tested now — and the cause turned out to be one layer deeper than I described.

I built 32.2.2 from source (Linux Mint 22, Qt 6.4.2, PipeWire 1.0.5) to get a control I could trust, reproduced the bug with the unmodified build, then patched and rebuilt. Same machine, same camera, same session, one file changed.

Before and after

	unmodified	patched
preview	three horizontal bands, green	correct image
frame rate	11.82 / 30 fps	30.00 / 30 fps
CPU	81.6 %	8.2 %

The performance figures are worth a second look: unmodified, OBS spent most of its time working on memory that was not part of the frame.

What is actually wrong

linesize was only half of it. On this hardware the producer delivers NV12 as a single data block with both planes contiguous — buffer->n_datas is 1. The loop in process_video_async() therefore never touches index 1 at all: out.data[1] stays NULL and out.linesize[1] stays 0. The chroma pointer is missing, not just its stride.

That also explains the progression while testing: setting linesize alone removed the bands and fixed the frame rate, but the image stayed green, because the chroma plane still was not being passed at all.

The patch

--- a/plugins/linux-pipewire/pipewire.c
+++ b/plugins/linux-pipewire/pipewire.c
@@ -688,6 +688,10 @@ static void process_video_async(obs_pipewire_stream *obs_pw_stream)
 
 	for (uint32_t i = 0; i < buffer->n_datas && i < MAX_AV_PLANES; i++) {
 		out.data[i] = buffer->datas[i].data;
+		if (buffer->datas[i].chunk->stride > 0)
+			out.linesize[i] = buffer->datas[i].chunk->stride;
+		else if (i > 0)
+			out.linesize[i] = out.linesize[0];
 		if (out.data[i] == NULL) {
 			blog(LOG_ERROR, "[pipewire] Failed to access data");
 			goto done;
@@ -702,6 +706,16 @@ static void process_video_async(obs_pipewire_stream *obs_pw_stream)
 	}
 #endif
 
+	/*
+	 * NV12 delivered as a single block: both planes are contiguous,
+	 * so derive the chroma plane instead of leaving it unset.
+	 */
+	if (buffer->n_datas == 1 && out.format == VIDEO_FORMAT_NV12) {
+		out.data[1] = out.data[0] +
+			      (size_t)out.linesize[0] * out.height;
+		out.linesize[1] = out.linesize[0];
+	}
+
 	obs_source_output_video(obs_pw_stream->source, &out);
 
 done:

This is deliberately minimal — it covers the one format I can verify here. A general solution would derive every plane's offset and stride from the format description rather than special-casing NV12, but I did not want to guess at formats I cannot test.

Cross-checks

• The remaining darkness of the image is the camera, not the code: cam --capture on the same node at the same size reports the same mean luminance.
• The front camera is black at 640x480 outside OBS as well (cam reports a mean of 0, while 1280x720 gives 17–43), so that is a separate, sensor-side issue.
• The rear camera delivers 300 of 300 frames at ~90 fps through cam, so the sensor is not the limit.

One separate observation

With the patch in place the stream still drops periodically, and the log shows why:

[camera-portal] Selected format for '...CAMR'
[pipewire] Renegotiating stream
error: [pipewire] Error res:-32 (Broken pipe): connection error
[pipewire] Stream state: "unconnected" (error: connection error)

The format-selected callback fires repeatedly and renegotiates each time. That is independent of the plane handling above and may be related to #10180 — I mention it only so it is not mistaken for a side effect of this patch.

Happy to adjust the patch if you would prefer a general plane derivation, and I can test any revision on this hardware.