[libcamera-devel] Need help with RaspberryPI pipeline bringup on Android
Roman Stratiienko
r.stratiienko at gmail.com
Fri Nov 12 17:33:16 CET 2021
Hi Naush,
Thank you for the update.
I've tested v2, and still got a picture freeze and some crashes.
Logs has been attached here:
https://github.com/kbingham/libcamera/issues/31#issuecomment-967248091
Regards,
Roman.
ср, 10 нояб. 2021 г. в 20:06, Naushir Patuck <naush at raspberrypi.com>:
>
> Hi Roman,
>
> Thanks for the update.
>
> Unfortunately I don't really understand why removing that change gets your environment working. I think I probably need some guidance from the libcamera team about buffer allocations happening in the android layer. Perhaps you can post a log of your new errors?
>
> The buffer allocation change, while not critical, really wants to go in with this series. So hopefully we can come to some conclusion soon.
>
> Regards,
> Naush
>
> On Wed, 10 Nov 2021, 4:47 pm Roman Stratiienko, <r.stratiienko at gmail.com> wrote:
>>
>> Oh it works perfectly if I revert [PATCH 2/3] pipeline: raspberrypi:
>> Rework the internal buffer allocation scheme
>>
>>
>>
>> ср, 10 нояб. 2021 г. в 18:25, Roman Stratiienko <r.stratiienko at gmail.com>:
>> >
>> > Hi Naush,
>> >
>> > Thank you for the patches.
>> > I tested my setup with them and it made the behaviour slightly
>> > different. Now the camera app draws the first frame and freezes.
>> > I'm now playing with overallocation. Meanwhile I would like to ask one thing.
>> > Cache hit is determined by comparing file descriptors and sizes of the buffers.
>> > Is it safe to do in case of external buffers? FD may be different for
>> > the same buffer, using inode for this purpose looks like a better
>> > solution.
>> > What do you think?
>> >
>> > вт, 9 нояб. 2021 г. в 15:39, Roman Stratiienko <r.stratiienko at gmail.com>:
>> > >
>> > > вт, 9 нояб. 2021 г. в 15:35, Naushir Patuck <naush at raspberrypi.com>:
>> > > >
>> > > > Hi Roman,
>> > > >
>> > > > On Tue, 9 Nov 2021 at 13:28, Roman Stratiienko <r.stratiienko at gmail.com> wrote:
>> > > >>
>> > > >> To make Android happy I've applied one patch:
>> > > >>
>> > > >> --- a/src/libcamera/pipeline/raspberrypi/raspberrypi.cpp
>> > > >> +++ b/src/libcamera/pipeline/raspberrypi/raspberrypi.cpp
>> > > >> @@ -429,9 +429,10 @@ CameraConfiguration::Status
>> > > >> RPiCameraConfiguration::validate()
>> > > >> rawCount++;
>> > > >> } else {
>> > > >> + cfg.bufferCount = 3;
>> > > >> outSize[outCount] = std::make_pair(count, cfg.size);
>> > > >> /* Record the largest resolution for fixups later. */
>> > > >> if (maxSize < cfg.size) {
>> > > >>
>> > > >> (Similar are done in other pipelines).
>> > > >>
>> > > >> And it seems to me that it somehow conflicts with raspberrypi pipeline
>> > > >> internals.
>> > > >
>> > > >
>> > > > The problem seems to be the number of cache slots is not set up correctly for your usage.
>> > > > From what I can gather, the Android layer allocated its own buffers to use by the pipeline
>> > > > handler, but the number of cache slots the pipeline handler allocates is smaller than
>> > > > the total number of buffers available. Hence the failure where the cache may not be able
>> > > > to find a free slot to use.
>> > > >
>> > > > I've been meaning to address this bit of logic for a long time now, so perhaps this is
>> > > > a good time to do this. It's not a big change, but there are certain assumptions to be made
>> > > > to balance between over allocation and loss of performance. I will post a patch soon, would
>> > > > you be able to try it out in your environment and report if it solves your issue?
>> > >
>> > >
>> > > Sure. With great pleasure.
>> > >
>> > >
>> > > >
>> > > > Thanks,
>> > > > Naush
>> > > >
>> > > >>
>> > > >>
>> > > >> вт, 9 нояб. 2021 г. в 13:54, Roman Stratiienko <r.stratiienko at gmail.com>:
>> > > >> >
>> > > >> > Hi Naushir,
>> > > >> >
>> > > >> > Thanks a lot for your support. You were right, it returns with error
>> > > >> > in that place. I'm correctly investigating why there is no buffer in
>> > > >> > the cache.
>> > > >> >
>> > > >> > вт, 9 нояб. 2021 г. в 12:32, Naushir Patuck <naush at raspberrypi.com>:
>> > > >> > >
>> > > >> > >
>> > > >> > > On Tue, 9 Nov 2021 at 10:26, Naushir Patuck <naush at raspberrypi.com> wrote:
>> > > >> > >>
>> > > >> > >> Hi Roman,
>> > > >> > >>
>> > > >> > >> Not sure if the email thread is the best place to discuss your issue, so perhaps create a bug report at bugs.libcamera.org.
>> > > >> > >> Onto the actual issue - it seems like the ISP gets starved of request buffers and fails to produce output and the pipeline handler stalls.
>> > > >> > >> The reason it gets starved is likely to be due to the following errors in the log:
>> > > >> > >>
>> > > >> > >> 10-07 14:37:46.726 360 442 D libcamera: DEBUG RPISTREAM rpi_stream.cpp:226 Queuing buffer 1048579 for ISP Output1
>> > > >> > >> 10-07 14:37:46.727 360 442 E libcamera: ERROR RPISTREAM rpi_stream.cpp:231 Failed to queue buffer for ISP Output1
>> > > >> > >> 10-07 14:37:46.727 360 442 D libcamera: DEBUG RPISTREAM rpi_stream.cpp:226 Queuing buffer 1048580 for ISP Output1
>> > > >> > >> 10-07 14:37:46.727 360 442 E libcamera: ERROR RPISTREAM rpi_stream.cpp:231 Failed to queue buffer for ISP Output1
>> > > >> > >> 10-07 14:37:46.727 360 442 D libcamera: DEBUG RPISTREAM rpi_stream.cpp:226 Queuing buffer 1048581 for ISP Output1
>> > > >> > >> 10-07 14:37:46.728 360 442 E libcamera: ERROR RPISTREAM rpi_stream.cpp:231 Failed to queue buffer for ISP Output1
>> > > >> > >>
>> > > >> > >> I cannot tell further why the qbuf ioctl has failed. Perhaps something in dmesg would tell us? Could you expand on how your request
>> > > >> > >> buffers have been allocated?
>> > > >> > >
>> > > >> > >
>> > > >> > > Just a pointer for you to investigate... The logs suggest that V4L2VideoDevice::queueBuffer() fails at:
>> > > >> > >
>> > > >> > > ret = cache_->get(*buffer);
>> > > >> > > if (ret < 0)
>> > > >> > > return ret;
>> > > >> > >
>> > > >> > > as all other error paths through that function log a message, and we see none. So it may not necessarily be the ioctl that fails.
>> > > >> > >
>> > > >> > > Naush
>> > > >> > >
>> > > >> > >>
>> > > >> > >>
>> > > >> > >> Thanks,
>> > > >> > >> Naush
>> > > >> > >>
>> > > >> > >>
>> > > >> > >> On Mon, 8 Nov 2021 at 20:20, Roman Stratiienko <r.stratiienko at gmail.com> wrote:
>> > > >> > >>>
>> > > >> > >>> Yes, I am on the very latest rpi branch without any custom patches. I had to upgrade it because of new media control used in mainline libcamera.
>> > > >> > >>>
>> > > >> > >>> пн, 8 нояб. 2021 г., 22:12 Kieran Bingham <kieran.bingham at ideasonboard.com>:
>> > > >> > >>>>
>> > > >> > >>>> Hi Roman,
>> > > >> > >>>>
>> > > >> > >>>> Quoting Roman Stratiienko (2021-11-08 17:46:56)
>> > > >> > >>>> > Hi guys,
>> > > >> > >>>> >
>> > > >> > >>>> > I have stuck with camera bring-up for Android. Could somebody who has
>> > > >> > >>>> > experience in it help me to find a right way to solve this. Logs are
>> > > >> > >>>> > available here:
>> > > >> > >>>> > https://github.com/kbingham/libcamera/issues/31
>> > > >> > >>>>
>> > > >> > >>>> The RPi kernel, and pipeline handler have had a large change recently to
>> > > >> > >>>> convert to using MediaController. It may require ensuring you have the
>> > > >> > >>>> latest kernel from RPi, along with the latest libcamera.
>> > > >> > >>>>
>> > > >> > >>>> You mentioned that you have " rpi-kernel v5.10.y", do you know if this
>> > > >> > >>>> contains the commits that update to the new MediaController drivers?
>> > > >> > >>>>
>> > > >> > >>>> I assume you are building your own kernel, so you'll want to make sure
>> > > >> > >>>> you're on the (very, very) latest branch, and it might be something to
>> > > >> > >>>> check on the RPi forums otherwise.
>> > > >> > >>>>
>> > > >> > >>>> --
>> > > >> > >>>> Kieran
>> > > >> > >>>>
>> > > >> > >>>>
>> > > >> > >>>> >
>> > > >> > >>>> > Thanks in advance,
>> > > >> > >>>> > Roman
More information about the libcamera-devel
mailing list