| Age | Commit message (Collapse) | Author |
|---|
|
Control the framerate by passing the controls::FrameDurationLimits
during Camera::start(). Framerate in gstreamer is expressed as
GST_TYPE_FRACTION so we maximise on maintaining it as a fraction
throughout and only do arithematic computations as and when required
(to compute frame-duration and vice-versa).
To weed out abritrary framerate as input, place the clamping via the
controls::FrameDurationLimits provided after camera::configure() phase.
This is handled by a helper function
gst_libcamera_clamp_and_set_frameduration().
Set the bound checked framerate (done in the above mentioned helper)
into the caps and pass the ControlList containing the frame-duration
to Camera::start(ctrls).
Signed-off-by: Rishikesh Donadkar <rishikeshdonadkar@gmail.com>
Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
Tested-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
|
|
Configure the camera before exposing the caps valid controls values
(and bounds) are available. These control values might be of interest
to be exposed on the capabilites, which otherwise, would not be
available if the camera is configured after the update caps event.
For instance, the FrameDurationLimits are computed by RPi's IPA in
its configure(). Hence, we need to Camera::configure() to happen in
order to know the FrameDurationLimits, that can be exposed in the caps.
This ties into the framerate support for libcamerasrc which will happen
in a follow-up commit.
Signed-off-by: Rishikesh Donadkar <rishikeshdonadkar@gmail.com>
Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
Tested-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
GST_VIDEO_TRANSFER_BT601 and GST_VIDEO_TRANSFER_BT2020_10 macros are
defined in GST Version 1.18.0.
Usage of these macros causes gstlibcamera compilation failure if
GST_VERSION < 1.18.0. These macros are used only if GST_VERSION >= 1.18.0.
Fix the following compilation error:
../src/gstreamer/gstlibcamera-utils.cpp:157:7: error: ‘GST_VIDEO_TRANSFER_BT601’ was not declared in this scope; did you mean ‘GST_VIDEO_TRANSFER_BT709’?
157 | case GST_VIDEO_TRANSFER_BT601:
| ^~~~~~~~~~~~~~~~~~~~~~~~
| GST_VIDEO_TRANSFER_BT709
../src/gstreamer/gstlibcamera-utils.cpp:159:7: error: ‘GST_VIDEO_TRANSFER_BT2020_10’ was not declared in this scope; did you mean ‘GST_VIDEO_TRANSFER_BT2020_12’?
159 | case GST_VIDEO_TRANSFER_BT2020_10:
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
| GST_VIDEO_TRANSFER_BT2020_12
Fixes: fc9783acc608 ("gstreamer: Provide colorimetry <> ColorSpace mappings")
Signed-off-by: Vedant Paranjape <vedantparanjape160201@gmail.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Tested-by: Rishikesh Donadkar <rishikeshdonadkar@gmail.com>
Reviewed-by: Rishikesh Donadkar <rishikeshdonadkar@gmail.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
|
|
Provide colorimetry <=> libcamera::ColorSpace mappings via:
- GstVideoColorimetry colorimetry_from_colorspace(colorspace);
- ColorSpace colorspace_from_colorimetry(colorimetry);
Read the colorimetry field from caps into the stream configuration.
After stream validation, the sensor supported colorimetry will
be retrieved and the caps will be updated accordingly.
Colorimetry support for gstlibcamera currently undertakes only one
argument. Multiple colorimetry support shall be introduced in
subsequent commits.
Signed-off-by: Rishikesh Donadkar <rishikeshdonadkar@gmail.com>
Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
|
|
libcamerasrc only supports three RGB formats. Adding the other RGB
formats supported by libcamera is trivial, do so.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Tested-by: Xavier Roumegue <xavier.roumegue@oss.nxp.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
|
|
The message.h and mutex.h headers are not used in the libcamera public
API. Make them private to avoid there usage in applications, and to
prevent having to maintain them with a stable ABI.
As mutex.h is used by libcamerasrc, the GStreamer element must switch
from the libcamera_public to the libcamera_private dependency.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Use the std::vector::back() instead of [0] index which corresponds
to std::vector::push_back() for tracking of pads. This doesn't
introduce a functional change as the gst_libcamera_src_init() will
only add one pad but it helps with readability.
Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Previously, ControlList::get<T>() would use default constructed objects to
indicate that a ControlList does not have the requested Control. This has
several disadvantages: 1) It requires types to be default constructible,
2) it does not differentiate between a default constructed object and an
object that happens to have the same state as a default constructed object.
std::optional<T> additionally stores the information if the object is valid
or not, and therefore is more expressive than a default constructed object.
Signed-off-by: Christian Rauch <Rauch.Christian@gmx.de>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
The task run function races with two other threads that want to resume
the task: the requestCompleted() handler and the buffer-notify signal
handler. If the former queues completed requests or the latter queues
back buffers to the pool, and then resume the task, after the task run
handler checks the queues but before it attemps to pause the task, then
the task may be paused without noticing that more work is available.
The most immediate way to fix this is to take the stream_lock in the
requestCompleted() and buffer-notify signal handlers, or cover the whole
task run handler with the GstLibcameraSrcState lock. This could cause
long delays in the requestCompleted() handler, so that's not a good
option.
Instead, pause the task unconditionally at the beginning of its run
function, and track while processing buffers and requests if the task
needs to be resumed. It may also get resumed externally by the
buffer-notify signal handler or the request completion handler, which
are guaranteed not to race due to the lock taken by the gst_task_pause()
and gst_task_resume() functions.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
|
|
Simplify the task run function futher by moving the processing of
completed requests to a separate function. No functional change
intended, only increased readability.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
|
|
In order to prepare for creation and queuing of multiple requests, move
the request creation and queueing code to a separate function. No
functional change intended.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
|
|
The srcpads_ vector is protected by two different locks, the GstObject
lock of the libcamerasrc element, and the stream_lock that covers the
run function of the thread. This isn't correct. Use the stream_lock
consistently to protect the pads.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
|
|
Add a new lock to the GstLibcameraSrcState class to protect the queued
and completed requests queues. This replaces the GstObject lock, and
minimizes the lock contention between the request completion handler and
the task run handler as the former must run as fast as possible.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
|
|
This simplifies the code, and allows removing the internal queue in the
GstLibcameraPad object.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
|
|
Move the request wrap to a completed queue in the request completion
handler to move more of the request completion processing to the
libcamerasrc task. This lowers the amount of time spent in the
completion handler, and prepares for reworking the usage of locks.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
|
|
To prepare for the addition of a completed requests queue, rename the
existing queued requests queue from requests_ to queuedRequests_.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
|
|
The buffer pts and the pad latency are computed from the framebuffer
timestamp, separately for each pad. Use the sensor timestamp provided
through the request metadata instead, to compute the values once outside
of the pads loop.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
|
|
For symmetry with RequestWrap::removeBuffer(), pass the Stream pointer
to addBuffer(). This handles streams at the GstPad level instead of the
GstBuffer level, which allows making the GstLibcameraPool API a bit
cleaner by removing the gst_libcamera_buffer_get_stream() helper
function.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
|
|
The GstBuffer variable in GstLibcameraSrcState::requestCompleted() is
only used within the loop scope. Make it a local loop variable.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
|
|
The gst_libcamera_resume_task() helper is an implementation of the
gst_task_resume() function that predates its addition to GStreamer. Use
gst_task_resume() when available, and rename gst_libcamera_resume_task()
to gst_task_resume() to support older GStreamer versions.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Vedant Paranjape <vedantparanjape160201@gmail.com>
|
|
Possibly the most trivial patch.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
The libcamera coding style has libcamera headers after system headers,
and before any other library headers.
Move the libcamera headers above the Gst headers accordingly.
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
|
|
For consistency with UniqueFD, rename the fd() function to get().
Renaming UniqueFD::get() to fd() would have been another option, but was
rejected to keep as close as possible to the std::shared_ptr<> and
std::unique_ptr<> APIs.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
|
|
Remove the verbose #ifndef/#define/#endif pattern for maintaining
header idempotency, and replace it with a simple #pragma once.
This simplifies the headers, and prevents redundant changes when
header files get moved.
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com>
|
|
Currently, the gst_libcamera_device_new() function assumes that a call to
Camera::generateConfiguration() will always succeed, but that may not be
the case and the return value must to be checked.
Otherwise, this could lead to a NULL pointer dereference if the pipeline
handler fails to generate a config for the VideoRecording stream role.
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Fix all name in all instances of the function gst_libcamera_get_camera_mananger
to gst_libcamera_get_camera_manager. Spelling of manager was incorrect.
This patch has no functional changes.
Signed-off-by: Vedant Paranjape <vedantparanjape160201@gmail.com>
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
The global pointer pointing to libcamera's CameraManager isn't used
outside of the gstlibcamera-utils.cpp compilation unit. Make it static.
Signed-off-by: Vedant Paranjape <vedantparanjape160201@gmail.com>
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Reviewed-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Existing pipeline handlers already support planar YUV formats.
Extend the gstreamer format map to incorporate them.
While here, split the formats into distinct groups.
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
|
|
The plane length is the length of the plane size. The buffer length
to be allocated for a plane is the offset and the length of
FrameBuffer::Plane.
Signed-off-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Pipeline managers sets a default value to StreamConfiguration::size. The
original fixation code was attempting to use it, but as it was truncating
the caps to its first structure it would never actually find a best match.
In this patch, instead of truncating, we weight various matches using the
product of the width and height delta. We also split delta from ranges
apart and prefer fixed size over them as ranges are not reliable.
This patch also removes the related todo, as it seems that libcamera core
won't go further then providing this default value and won't be sorting the
format and size lists.
Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Tested-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
It's not allowed in GStreamer to push events while holding the object
lock. This reduce the scope into which we hold the object lock. In
fact we don't need to protect against gst_task_resume() concurrency
when we stop the task as resume only do something if the task is paused.
This fixes a deadlock when running multiple instances of libcamerasrc
and closing one of the streaming window.
Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Tested-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
It's not allowed to have multiple instances of CameraManager. This
requirement is not easy for GStreamer were the device monitor and
the camerasrc, or two camerasrc instances don't usually have any
interaction between each other. Fix this by implementing a minimalist
singleton around CameraManager constructor and start()/stop()
operations.
Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Tested-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
This deadlock occurs when a buffer is holding the last reference on
the allocator. In gst_libcamera_allocator_release() we must drop the
object lock before dropping the last ref of that object since the
destructor will lock it again causing deadlock.
This was notice while switching camera or resolution in Cheese software.
Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Tested-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Change format specifier %s to %u in name template field of request pad
template.
Pad names are as follows, src_0, src_1, etc. So, instead of using string
format specifier, use unsigned integer format specifier.
Signed-off-by: Vedant Paranjape <vedantparanjape160201@gmail.com>
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
|
|
This patch adds group_id in GstLibcameraSrcState, since group_id is
something which should be same for all the pads, it can be reused
later.
Signed-off-by: Vedant Paranjape <vedantparanjape160201@gmail.com>
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
|
|
Now that we have a libcamera_private, make the public only dependency
libcamera_public so that it is clear which interface is being linked.
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
This patch adds support for using request pads in libcamerasrc Gst
Element. It allows a user to request multiple streams if the platform
supports multistream output using libcamera.
This was tested on Raspberry Pi 4B+ with a camera connected to CSI port.
It can be tested by running the following command
gst-launch-1.0 libcamerasrc camera-name="<camera-name-here>" name=src src.src ! queue ! videoconvert ! autovideosink src.src_0 ! queue ! videoconvert ! autovideosink
Signed-off-by: Vedant Paranjape <vedantparanjape160201@gmail.com>
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
|
|
The return value from generateConfiguration() was not checked. Only assert
was added as a guard which checked if the size of the generated camera
config was equal to size of roles passed to it.
If the roles variable has an invalid/unsupported role, it will return
a nullptr and then trying to access a member on a nullptr for size comparison
will result in a segmentation fault. So, if the function returns a nullptr,
simply push an error message on GstBus and gracefully exit.
Signed-off-by: Vedant Paranjape <vedantparanjape160201@gmail.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
|
|
GLib 2.62 has deprecated g_memdup(), which is used inline in GStreamer's
gstbytereader.h header. This results in a compilation warning:
In file included from /usr/include/gstreamer-1.0/gst/base/base.h:35,
from ../../src/gstreamer/gstlibcamerasrc.cpp:39:
/usr/include/gstreamer-1.0/gst/base/gstbytereader.h: In function ‘guint8* gst_byte_reader_dup_data_unchecked(GstByteReader*, guint)’:
/usr/include/gstreamer-1.0/gst/base/gstbytereader.h:365:41: error: ‘void* g_memdup(gconstpointer, guint)’ is deprecated: Use 'g_memdup2' instead [-Werror=deprecated-declarations]
365 | return (guint8 *) g_memdup (data, size);
GLib has a mechanism to silence warnings introduced in newer versions,
to allow compilation without warnings on multiple versions of the
library. This is done by setting the GLIB_VERSION_MIN_REQUIRED macro to
the minimum GLib version required.
As we depend on GStreamer >= 1.14, set the minimum GLib version to 2.40.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Tested-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
|
|
Add the application and adaptation layers being built to the meson
summary. The summary now prints
libcamera 0.0.0
Configuration
Enabled pipelines: ipu3
raspberrypi
rkisp1
simple
uvcvideo
vimc
Android support: True
GStreamer support: True
V4L2 emulation support: True
cam application: True
qcam application: True
Unit tests: True
Subprojects
libyuv: YES
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
|
|
Reduce the indentation in the gstreamer and qcam meson.build with
subdir_done(). This follows similar patterns in cam and v4l2.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Currently, when allocating buffers, the streams of the Camera object are
used. Instead the streams of the CameraConfiguration object should be
used. This is because the Camera object holds all available streams
while the CameraConfiguration holds only the streams associated with the
current configuration.
Signed-off-by: Dafna Hirschfeld <dafna.hirschfeld@collabora.com>
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
If gst_buffer_pool_acquire_buffer in gst_libcamera_task_run fails, the
unique_ptr to the request-object gets reset and hence, its destructor
is called. However, the wrap-object points to the same object and is
still alive at this moment. When the task_run-function is finished, the
destructor of the wrap-object is called, which in return calls the
destructor of the request-object again.
Instead of taking care of both, the request and the wrap-object, we can
move the request to the wrap which will then effectively take care of
the request object automatically.
Signed-off-by: Marian Cichy <m.cichy@pengutronix.de>
Suggested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
|
|
We borrowed a GstBuffer from the pool, if preparing the buffer failed,
we need to push it back to avoid leaking it.
Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Both the DeviceProvider and Device classes had the same mistake,
calling G_OBJECT_GET_CLASS() instead of G_OBJECT_CLASS() when
chaining their finalize call to their base class. This would
crash at destruction, which was causing gst-device-monitor-1.0
tool to crash and application using that API to crash too.
Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
The meson.build files mix array declarations with and without a space
after the opening and before the closing square bracket. The vast
majority of cases don't use spaces, so standardize on that.
While it it, fix indentation in a few places.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
When closing the libcamerasrc, the reference to camera is released and
the camera manager is stopped. However, the camera configuration still
exists at that point, and holds a reference to the camera. This leads to
a warning from the device enumerator complaining that the media devices
are still in use:
[1:53:48.792327560] [408] ERROR DeviceEnumerator device_enumerator.cpp:165 Removing media device /dev/media1 while still in use
[1:53:48.792354022] [408] ERROR DeviceEnumerator device_enumerator.cpp:165 Removing media device /dev/media0 while still in use
A crash follows when the libcamerasrc is finalized, as deleting the
camera configuration will then release the last reference to the camera,
which attempts to delete the camera object with deleteLater() without an
event dispatcher.
Fix it by deleting the camera configuration before stopping the camera
manager.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
|
|
Macros used in gstreamer (e.g. G_DEFINE_TYPE) are functions. The
end semicolons with the macros are unnecessary.
Signed-off-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Allow reuse of the Request object by implementing reuse(). This means
the applications now have the responsibility of freeing the Request
objects, so make all libcamera users (cam, qcam, v4l2-compat, gstreamer,
android) do so.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
We build libcamera with -Wno-unused-parameter and this doesn't cause
much issue internally. However, it prevents catching unused parameters
in inline functions defined in public headers. This can lead to
compilation warnings for applications compiled without
-Wno-unused-parameter.
To catch those issues, remove -Wno-unused-parameter and fix all the
related warnings with [[maybe_unused]].
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
|
