[libcamera-devel] Regression in commit 86a47fdcd97350bd979a4d6b00124330a3b02441

[David Plowman]

Hi again

Still struggling here, and finding various buffer sizes seem to be
messed up. When it "invents" these fake multiple planes, it seems to
be using the image width as the stride (or "bytesperline" sometimes),
with the result that all the buffer lengths end up too short. The code
I'm looking at is towards the end of V4L2VideoDevice::createBuffer. I
notice a "\todo Take the V4L2 stride into account" there... Strides
*MUST* take into account the numbers coming out of the hardware
because it has specific alignment constraints.

We're actually trying to put our libcamera-apps into our new OS
releases and are unfortunately finding that EVERYTHING is crashing all
over the place with seg faults. Any help would be appreciated.

Thanks
David

On Fri, 3 Sept 2021 at 14:21, David Plowman
<david.plowman at raspberrypi.com> wrote:
>
> Hi everyone
>
> We're having a bit of a problem with this commit ("libcamera:
> framebuffer: Add offset to FrameBuffer::Plane").
>
> We use only single plane buffers in all our code and previously
> FrameBuffers would advertise having only one plane
> (frameBuffer.planes().size() would be 1), and the length would be the
> full length of the plane (all of the Y and U and V pixels). We'd use
> this information to mmap the buffer and give us a pointer. And in
> fact, we'd quite often check that there's only one plane because (for
> example) our codec driver doesn't support mplane formats.
>
> Since this commit, everything is now showing up as 3 planes, and each
> has a length field just for a part of the plane, so the first "plane"
> would just be the Y, and so on.
>
> Now, I can loop through all the planes with the same fd and add up all
> the lengths, and then mmap my buffer as before, but I guess I'm
> wondering why this has changed. After all, it's *not* a multi-plane
> buffer and we want to know, only now it seems harder to tell the
> difference.
>
> Any thoughts?
>
> Thanks!
> David