| Age | Commit message (Collapse) | Author |
|---|
|
The child proxy interface is needed in order to allow setting
properties on pad using parse launch syntax.
Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Without the camera manager, it is not possible to cleanly delete the
FrameBufferAllocator object. Keep the camera manager alive until all the
memory object have been released.
A shared_ptr to the CameraManager is introduced which is itself stored
as a plain pointer and allocated and released explicitly. When more
than one C++ member is required, this can be refactored to use a new C++
class, but the struct _GstLibcameraAllocator is allocated and freed by
glib, so it does not have automatic destruction presently.
Bug: https://bugs.libcamera.org/show_bug.cgi?id=211
[Kieran: Update test framework to remove expected test fail]
Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
The GstAtomicQueue only supports 2 threads, one pushing, and one
popping. We pop and push on error cases and we may have multiple threads
downstream returning buffer (using tee), which breaks this assumption.
On top of which, the release function, that notifies when the queue goes
from empty to not-empty relies on a racy empty check. The downstream
thread that does this check is effectively concurrent with our thread
calling acquire().
Fix this by replacing the GstAtomicQueue with a std::deque, and protect
access to that using the object lock.
Bug: https://bugs.libcamera.org/show_bug.cgi?id=201
Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Acked-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
This is more efficient since only a single vector will be constructed,
and furthermore, it prevents the TOCTOU issue that might arise when
the list of cameras changes between the two queries.
Signed-off-by: Barnabás Pőcze <pobrn@protonmail.com>
Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
The camera name is copied in gst_libcamera_src_open() as we can't hold
the lock protecting the name while calling GST_ELEMENT_ERROR(). The
GST_ELEMENT_ERROR() macro sends a message on the bus, taking more locks
and possibly causing issues.
However, the current code makes the copy, but does not actually use it.
So fix that.
Fixes: 58feb69f852289 ("gst: libcamerasrc: Implement selection and acquisition")
Signed-off-by: Barnabás Pőcze <pobrn@protonmail.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
The string returned by `gst_video_colorimetry_to_string()`
has to be freed, this was missing.
Fixes: fc9783acc6083a ("gstreamer: Provide colorimetry <> ColorSpace mappings")
Signed-off-by: Barnabás Pőcze <pobrn@protonmail.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>
|
|
Source files in libcamera start by a comment block header, which
includes the file name and a one-line description of the file contents.
While the latter is useful to get a quick overview of the file contents
at a glance, the former is mostly a source of inconvenience. The name in
the comments can easily get out of sync with the file name when files
are renamed, and copy & paste during development have often lead to
incorrect names being used to start with.
Readers of the source code are expected to know which file they're
looking it. Drop the file name from the header comment blocks in all
remaining locations that were not caught by the automated script as they
are out of sync with the file name.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com>
|
|
Source files in libcamera start by a comment block header, which
includes the file name and a one-line description of the file contents.
While the latter is useful to get a quick overview of the file contents
at a glance, the former is mostly a source of inconvenience. The name in
the comments can easily get out of sync with the file name when files
are renamed, and copy & paste during development have often lead to
incorrect names being used to start with.
Readers of the source code are expected to know which file they're
looking it. Drop the file name from the header comment block.
The change was generated with the following script:
----------------------------------------
dirs="include/libcamera src test utils"
declare -rA patterns=(
['c']=' \* '
['cpp']=' \* '
['h']=' \* '
['py']='# '
['sh']='# '
)
for ext in ${!patterns[@]} ; do
files=$(for dir in $dirs ; do find $dir -name "*.${ext}" ; done)
pattern=${patterns[${ext}]}
for file in $files ; do
name=$(basename ${file})
sed -i "s/^\(${pattern}\)${name} - /\1/" "$file"
done
done
----------------------------------------
This misses several files that are out of sync with the comment block
header. Those will be addressed separately and manually.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com>
|
|
These formats are now defined in upstream GStreamer main branch, so it
is now safe to use their names. Note that libcamera only supports little
endian variants of these formats.
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>
|
|
This enables monochrome support in libcamerasrc.
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>
|
|
This change to the build system will prepend the plugin build directory
to GST_PLUGIN_PATH environment. This makes the built plugin visible to
GStreamer inside meson devenv enabling uninstalled testing. In order to
avoid polluting the user registry, the GST_REGISTRY environment is also
set.
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>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
The gst_clear_event() function used by libcamerasrc has been introduced
in GStreamer 1.16, while libcamera claims to need 1.14 or newer. This
causes a compilation error. Fix it by copying the gst_clear_event()
implementation to gstlibcamera-utils.h when compiling with older
GStreamer version.
The version check makes it clear that the workaround is needed with
older versions only, flagging it for removal when the minimum GStreamer
version requirement will be bumped.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
This commit implements renegotiation of the camera configuration and
source pad caps. A renegotiation can happen when a downstream element
decides to change caps or the pipeline is dynamically changed.
To handle a renegotiation the GST_FLOW_NOT_NEGOTIATED return value has
to be handled in GstLibcameraSrcState::processRequest(). Otherwise the
default would be to print an error and stop streaming.
To archive this in a clean way the if statement is altered into a switch
statement which now also has a case for GST_FLOW_NOT_NEGOTIATED. In the
case of GST_FLOW_NOT_NEGOTIATED every source pad is checked for the
reconfiguration flag with gst_pad_needs_reconfigure() which does not
clear this flag. If at least one pad requested a reconfiguration the
function returns without an error and the renegotiation will happen
later in the running task. If no pad requested a reconfiguration then
the function will return with an error.
In gst_libcamera_src_task_run() the source pads are checked for the
reconfigure flag by calling gst_pad_check_reconfigure() and if one pad
returns true and the caps are not sufficient anymore then the
negotiation is triggered. It is fine to trigger the negotiation after
only a single pad returns true for gst_pad_check_reconfigure() because
the reconfigure flags are cleared in the gst_libcamera_src_negotiate()
function.
If any pad requested a reconfiguration the following will happen:
1. The camera is stopped because changing the configuration may not
happen while running.
2. The completedRequests queue will be cleared by calling
GstLibcameraSrcState::clearRequests() because the completed buffers
have the wrong configuration.
3. The new caps are negotiated by calling gst_libcamera_src_negotiate().
When the negotiation fails streaming will stop.
4. The camera is started again.
Signed-off-by: Jaslo Ziska <jaslo@ziska.de>
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Tested-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Add a clearRequests() function to GstLibcameraSrcState which clears the
GstLibcameraSrcState::completedRequests_ queue.
Use this new function in gst_libcamera_src_task_leave() instead of doing
it manually.
Signed-off-by: Jaslo Ziska <jaslo@ziska.de>
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Tested-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Move the code which negotiates all the source pad caps into a separate
function called gst_libcamera_src_negotiate(). When the negotiation
fails this function will return false and true otherwise.
Use this function instead of doing the negotiation manually in
gst_libcamera_src_task_enter() and remove the now redundant error
handling code accordingly.
Signed-off-by: Jaslo Ziska <jaslo@ziska.de>
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Tested-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Commit fd84180d7a09 ("gstreamer: Implement element EOS handling") has
introduced a compilation warning with clang:
../../src/gstreamer/gstlibcamerasrc.cpp:768:23: error: unused variable 'oldEvent' [-Werror,-Wunused-variable]
g_autoptr(GstEvent) oldEvent = self->pending_eos.exchange(event);
^
This seems to be a false positive, but nonetheless breaks the build. Fix
it.
Fixes: fd84180d7a09 ("gstreamer: Implement element EOS handling")
Signed-off-by: Jaslo Ziska <jaslo@ziska.de>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
|
|
This commit implements EOS handling for events sent to the libcamerasrc
element by the send_event method (which can happen when pressing
Ctrl-C while running gst-launch-1.0 -e, see below). EOS events from
downstream elements returning GST_FLOW_EOS are not considered here.
To archive this add a function for the send_event method which handles
the GST_EVENT_EOS event. This function will set an atomic to the
received event and push this EOS event to all source pads in the running
task.
Also set the GST_ELEMENT_FLAG_SOURCE flag to identify libcamerasrc as a
source element which enables it to receive EOS events sent to the
(pipeline) bin containing it. This in turn enables libcamerasrc
to receive EOS events, for example, from gst-launch-1.0 with
the -e (--eos-on-shutdown) flag applied.
Bug: https://bugs.libcamera.org/show_bug.cgi?id=91
Signed-off-by: Jaslo Ziska <jaslo@ziska.de>
Acked-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
|
|
The meson style, which libcamera follows, recommends a space before
colons in function parameters. Fix the style violations through the
project.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
|
|
Now that `Camera::generateConfiguration()` takes a `libcamera::Span`
of `StreamRole`, remove the `StreamRoles` type, which was an alias
to `std::vector<libcamera::StreamRole>`.
The removal has two reasons:
- it is no longer strictly necessary,
- its presence may suggest that that is the preferred (or correct)
way to build/pass a list of `StreamRole`.
Signed-off-by: Barnabás Pőcze <pobrn@protonmail.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
[Kieran: Fix small checkstyle report on roles initialiser]
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Drop libcamera_private dependency entirely as to avoid libcamerasrc
getting more dependent on it. In order to achieve that, one of the
mutex locks in GstLibcameraSrcState needs to be replaced with GMutex.
However doing so, this won't let us to use the clang's thread annotation
macros in libcamera (which should be fine as libcamerasrc would move
out of libcamera repo once matured).
Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
|
|
Cameras such as the PiCam 3 support auto-focus, but the GStreamer plugin
for libcamera does not enable auto-focus. With this patch auto-focus can
be enabled for cameras that support it. By default it is disabled, which
means default behaviour remains unchanged. For cameras that do not
support auto-focus, an error message shows up if auto-focus is enabled.
This was tested on cameras that do not support auto-focus (e.g. PiCam2)
and was tested on a camera that does support auto-focus (PiCam3). The
test involved setting the focus to AfModeContinous and observing it.
However, by not setting "auto-focus-mode" or using AfModeManual as
the "auto-focus-mode" both resulting in auto-focus being disabled.
Bug: https://bugs.libcamera.org/show_bug.cgi?id=188
Signed-off-by: Cedric Nugteren <cedric@plumerai.com>
Reviewed-by: Maarten Lankhorst <dev@lankhorst.se>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Tested-by: Umang Jain <umang.jain@ideasonboard.com>
Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
|
|
Fixes build failure on some build environments.
Signed-off-by: Matti Lehtimäki <matti.lehtimaki@gmail.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Bayer8 support is useful on hardware such as Librem 5, as GStreamer
provides easy solution for debayering and display of the camera
data. Add necessary glue to libcamerasrc element.
Signed-off-by: Pavel Machek <pavel@ucw.cz>
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 StreamRole enum has enumerators such as 'Raw' that are too generic
to be in the global libcamera namespace. Turn it into a scoped enum to
avoid namespace clashes, and update users accordingly.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
The libcamerasrc element looks for the availability of the
FrameDurationLimits control by looking it up by numeric control id.
The ControlinfoMap::find(unsigned int i) function searches the control
numerical identifier on the ContorlInfoMap::idMap_ class member, which
might be not initialized if the pipeline handler does not register
any control, causing an invalid memory access.
Avoid looking up the control by numerical id and use the ControlId
instance instead to prevent that.
Fixes: ccfe0a1af77c ("gstreamer: Provide framerate support for libcamerasrc")
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
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>
|
