diff options
author | David Plowman <david.plowman@raspberrypi.com> | 2022-11-09 10:49:40 +0000 |
---|---|---|
committer | Kieran Bingham <kieran.bingham@ideasonboard.com> | 2022-11-14 11:03:32 +0000 |
commit | 75e7befb1667f620410f0f15a10eccb32d7df66d (patch) | |
tree | 9831a812562421e5f882fd2bf3852f00ed7ab760 /src/gstreamer/gstlibcameraallocator.cpp | |
parent | bf7226f4c46de0bbadff63eb531dbd3dd4c900a0 (diff) |
Revert "pipeline: raspberrypi: Do not unconditionally free buffers on close"
This reverts commit 30d704732badc675f72fe73d14749669cb645c23.
It turns out that this commit causes some regressions and is in fact
unnecessary because the related commit "libcamera: v4l2_videodevice:
Guard against releasing unallocated buffers"
(a2bdff6d0b67475492ac7cf9318866b6d89a28fd) fixes the problem
completely (if the buffers were never allocated, the video device
avoids trying to free them even if the pipeline handler asks).
The reason for the regressions is that in this new (broken) scheme we
would never call clearBuffers() on all the streams if the internal
buffers were never allocated (i.e. buffersAllocated_ is never
set). This causes the stream's bufferMap_ list to get longer and
longer if there are multiple back-to-back calls to configure, and
dev_->importBuffers() will ultimately to fail.
So either we need to think more carefully about how to stop the
pipeline handler from freeing buffers that it doesn't own, or we just
leave it as the other commit resolves the problem on its own. In the
interim, simply reverting this commit certainly seems like the best
solution.
Fixes: 30d704732bad ("pipeline: raspberrypi: Do not unconditionally free buffers on close")
Signed-off-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Naushir Patuck <naush@raspberrypi.com>
Acked-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Diffstat (limited to 'src/gstreamer/gstlibcameraallocator.cpp')
0 files changed, 0 insertions, 0 deletions