| Age | Commit message (Collapse) | Author |
|---|
|
The IspStatsRegion structure was introduced as an attempt to prepare for
a generic AWB algorithm structure. The structure name by itself is not
explicit and it is too optimistic to try and make a generic one for now.
Its role is to accumulate the pixels in a given zone. Rename it to
accumulator, and remove the uncounted field at the same time. It is
always possible to know how many pixels are not relevant for the
algorithm by calculating total-counted. The uncounted field was only
declared and not used. Amend the documentation accordingly.
Signed-off-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
The structure Ipu3AwbCell describes the AWB stats layout on the kernel
side. We will need it to be used by the AGC algorithm to be introduced
later, so let's make it visible from ipa::ipu3::algorithms and not only
for the AWB class.
The IspStatsRegion will be needed by AGC too, so let's move it in the
same namespace too.
Signed-off-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
CameraStream always sets the format of processor output buffer to
MJPEG. This fixes the issue.
Signed-off-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
|
|
The cause is that we read out delayed values using a frame's sequence
number (DelayedControls::get). But we fill the values up
(DelayedControls::applyControls) incrementing writeCount by only one
even if the sequence number has jumped by several since last
time. This is exactly what happens when frames are being dropped.
So the fix is to increment writeCount by "as much as the sequence
number has jumped since last time", which means that we just follow
the sequence number directly.
Bug: https://bugs.libcamera.org/show_bug.cgi?id=74
Signed-off-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Naushir Patuck <naush@raspberrypi.com>
Tested-by: Naushir Patuck <naush@raspberrypi.com>
Tested-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
It can be useful, for diagnosis purpose, to know what plane and CRTC the
KMS sink auto-selects. Print the display pipeline configuration at start
time.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
|
|
The key and value of the test pattern mode are originally the index of
v4l2 control and the corresponding test pattern mode control value.
This key and value are useful in the initialization for reporting
available test pattern modes. However, the map of the reversed key and
value is much more useful in applying a requested test pattern mode.
Reverses the key and value of the map as the initialization is one
time but the test pattern mode request will be multiple times.
Signed-off-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@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>
|
|
Remove header files which were not being used in the test code.
The following headers were removed from the gstreamer_single_stream_test:
- libcamera/base/utils.h
- libcamera/internal/source_paths.h
Signed-off-by: Vedant Paranjape <vedantparanjape160201@gmail.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
|
|
There is a possibility that an out-of-order completion of capture
request happens by calling process_capture_result() directly on error
paths. The framework expects that errors should be notified as soon as
possible, but the request completion order should remain intact.
An existing instance of this is abortRequest(), which sends the capture
results on flushing state, without considering order-of-completion.
Since we have a queue of Camera3RequestDescriptor tracking each
capture request placed by framework to libcamera HAL, we should be only
sending back capture results from a single location, by inspecting
the queue. As per the patch, this now happens in
CameraDevice::sendCaptureResults().
Each descriptor is now equipped with its own status to denote whether
the capture request is complete and ready to be send back to the
framework or needs to be waited upon. This ensures that the order of
completion is respected for the requests.
Since we are fixing out-of-order request completion in abortRequest(),
change the function to read from the Camera3RequestDescriptor directly,
instead of camera3_capture_request_t. The descriptor should have all the
information necessary to set the request buffers' state to error.
Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
abortRequest() and notifyError() do not modify any members of
CameraDevice hence, these functions can be const.
Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
The descriptors_ map holds Camera3RequestDescriptor(s) which are
per-capture requests placed by the framework to libcamera HAL.
CameraDevice::requestComplete() looks for the descriptor for which the
camera request has been completed and removes it from the map.
Since the requests are placed in form of FIFO and the framework expects
the order of completion to be FIFO as well, this calls for a need of
a queue rather than a std::map.
This patch still keeps the same lifetime of Camera3RequestDescriptor as
before i.e. in the requestComplete(). Previously, a descriptor was
extracted from the map and its lifetime was bound to requestComplete().
The lifetime is kept the same by manually calling .pop_front() on the
queue. In the subsequent commit, this is likely to change with a
centralized location of dropping descriptors from the queue for request
completion.
Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
Use Camera3RequestDescriptor as cookie for the Capture Request.
The cookie is used to lookup descriptors map in
CameraDevice::requestComplete(). The map will be transformed to a
queue in subsequent commit.
Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
Acquire fences for streams of type Mapped generated by
post-processing are not correctly handled and are currently
ignored by the camera HAL.
Fix this by adding CameraStream::waitFence(), executed before
starting the post-processing in CameraStream::process().
The change applies to all streams generated by post-processing (Mapped
and Internal) but currently acquire fences of Internal streams are
handled by the camera worker. Postpone that to post-processing time by
passing -1 to the Worker for Internal streams.
Also correct the release_fence handling for failed captures, as the
framework requires the release fences to be set to the acquire fence
value if the acquire fence has not been waited on.
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Tested-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Create local install_dir meson variable to store the full path to the
installation directory for the libcamera and ipa headers. This shortens
lines and avoids duplicating calls to get_option('includedir').
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
All libcamera headers are meant to be installed in
${prefix}/include/libcamera/libcamera, with pkgconfig specifying the
include directory as `-I ${prefix}/include/libcamera`. Applications then
include the headers with `#include <libcamera/camera.h>`.
The base and ipa headers are meant to be installed in subdirectories of
the libcamera headers directory, but are mistakenly installed one level
too high, in ${prefix}/include/libcamera. This leads to compilation
failures when including the base or ipa header.
Fix this by setting the meson libcamera_include_dir variable to the
libcamera headers directory. All other header paths are derived from
that variable and are now correct.
Reported-by: Dorota Czaplejewicz <dorota.czaplejewicz@puri.sm>
Bug: https://bugs.libcamera.org/show_bug.cgi?id=79
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
The libcamera and libcamera-base libraries are currently unversioned, but
donwstream users expect these to have a proper SONAME version in order to
package them.
A stable release has not yet happened because the project is still under
development and the API/ABI might change. But having a versioned SONAME
would allow distributions to package libcamera, without the need to add
any downstream patch to set the version.
Since the "0.0.0" version is already used in different places, let's also
use that as the library version. The meson build system will use the first
part of the version ("0") as the SONAME version, which is aligned with the
convention used by other projects:
$ ls /lib64/libcamera*so* -1
/lib64/libcamera-base.so
/lib64/libcamera-base.so.0
/lib64/libcamera-base.so.0.0.0
/lib64/libcamera.so
/lib64/libcamera.so.0
/lib64/libcamera.so.0.0.0
$ objdump -p /lib64/libcamera.so.0.0.0 | grep SONAME
SONAME libcamera.so.0
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
The Camera3RequestDescriptor containing the capture request is added to
the descriptors_ map after a call to CameraWorker::queueRequest(). This
is a race condition since CameraWorker::queueRequest() queues requests
to libcamera::Camera asynchronously. The requests may thus complete
before they get added to descriptors_, in which case requestComplete()
will fail to lookup the request in the map.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Signed-off-by: Umang Jain <umang.jain@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 idMap variable may be used uninitialized in the
ControlSerializer::deserialize<ControlList>() function as reported by
gcc 11:
../../src/libcamera/control_serializer.cpp: In member function ‘T libcamera::ControlSerializer::deserialize(libcamera::ByteStreamBuffer&) [with T = libcamera::ControlList]’:
../../src/libcamera/control_serializer.cpp:609:33: error: ‘idMap’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
609 | ControlList ctrls(*idMap);
|
This is due to a missing default case in a switch/case. Fix it by adding
the default case.
Fixes: 6b1404fc4836 ("libcamera: control_serializer: Fix usage of uninitialized variable")
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
The simple-cam application has a check to ensure that at least one
camera is present before attempting to access the first camera, to avoid
a crash. Update the application developer's guide to match this
behaviour.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
The return type of std::vector::size() is size_t. Use the same type,
instead of unsigned int, to store its return value when retrieving the
number of allocated buffers.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
The global "camera" variable isn't accessed outside of its compilation
unit. Make it static.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Generation of thumbnail is not occuring currently because
ANDROID_JPEG_THUMBNAIL_SIZE is not set for request metadata passed
to PostProcessorJpeg::process(). The commit 1264628d3c92("android:
jpeg: Configure thumbnailer based on request metadata") introduced
the mechanism to retrieve the thumbanil size from request metadata,
however it didn't add the counterpart i.e. inserting the size in
the request metadata in request metadata template, at the first place.
The patch fixes this issue by setting ANDROID_JPEG_THUMBNAIL_SIZE in
the request metadata template populated by
CameraCapabilities::requestTemplatePreview(). The value for
ANDROID_JPEG_THUMBNAIL_SIZE is set to be the first non-zero size
reported by static metadata ANDROID_JPEG_AVAILABLE_THUMBNAIL_SIZES.
Fixes: 1264628d3c92("android: jpeg: Configure thumbnailer based on request metadata")
Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
|
|
CameraMetadata's constructor take in number of entries and number of
bytes to be allocated for those entries. However, CameraMetadata is
already capable of resizing its container on the fly, in case more
entries are added to it. Hence, the numbers passed in during the
construction acts as hint values for initialization.
Clarify this in CameraCapabilities::requestTemplatePreview() and
remove the \todo, as the arguments and the \todo gives the perspective
that we need to be quite accurate with the numbers of entries / bytes,
which is not the case.
Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
|
|
Two independent instances of the ControlSerializer class are in use at
the IPC boundaries, one in the Proxy class that serializes data from the
pipeline handler to the IPA, and one in the ProxyWorker which serializes
data in the opposite direction.
Each instance operates autonomously, without any centralized point of
control, and each one assigns a numerical handle to each ControlInfoMap
it serializes. This creates a risk of potential collision on the handle
values, as both instances will use the same numerical space and
are not aware of what handles has been already used by the instance "on
the other side".
To fix that, partition the handles numerical space by initializing the
control serializer with a seed according to the role of the component
that creates the serializer and increment the handle number by 2, to
avoid any collision risk.
While this is temporary and rather hacky solution, it solves an issue
with isolated IPA modules without too much complexity added.
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
The ControlInfo class was originally designed to only transport
the control's minimum and maximum values which represent the control's
valid limits.
Later the default value of the control has been added to the ControlInfo
class, but the control serializer implementation has not been updated
accordingly.
This causes issues in IPA modules making use of ControlInfo::def() as,
when running in isolation, they would receive 0.
Fix that by serializing and deserializing the additional ControlValue
and update the protocol description accordingly.
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
When a ControlList is deserialized, the code searches for a valid
ControlInfoMap in the local cache and use its id map to initialize the
list. If no valid ControlInfoMap is found, as it's usually the case
for lists transporting libcamera controls and properties, the globally
defined controls::controls id map is used unconditionally.
This breaks the deserialization of libcamera properties, for which a
wrong idmap is used at construction time.
As the serialization header now transports an id_map_type field, store
the idmap type at serialization time, and re-use it at
deserialization time to identify the correct id map.
Also make the validation stricter by imposing to list of V4L2 controls to
have an associated ControlInfoMap available, as there is no globally
defined idmap for such controls.
To be able to retrieve the idmap associated with a ControlList, add an
accessor function to the ControlList class.
It might be worth in future using a ControlInfoMap to initialize the
deserialized ControlList to implement controls validation against their
limit. As such validation is not implemented at the moment, maintain the
current behaviour and initialize the control list with an idmap.
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
When running the IPA in isolated mode, each side of the IPC boundary
has an instance of the ControlSerializer class which is used to
serializer/deserialize controls before transmitting them on the wire.
The IPAProxyWorker, which creates and manages the process the IPA runs in,
does not reset its ControlSerializer upon an IPA::configure() call, while
the IPAProxy does, effectively creating a misalignment between the
two sides of the fence.
This obviously creates issues as one side of the IPC runs with a
populated and possibly stale cache of ControlInfoMap references, while the
other side gets reset every time a new configuration is applied to the
Camera.
Fix that by resetting the IPAProxyWorker ControlSerializer on an
IPA configure() call.
This change fixes an issue which is easily triggered by running two
consecutive capture sessions with the IPA running in isolated mode:
ERROR Serializer control_serializer.cpp:520 Can't deserialize ControlList: unknown ControlInfoMap
Fixes: 7832e19a599e ("utils: ipc: add templates for code generation for IPC mechanism")
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
The IPA::configure() function has an IPAConfigInfo parameters which
contains a map of numerical indexes to ControlInfoMap instances.
This is a leftover of the old IPA protocol, where it was not possible to
specify a rich interface as it is possible today and each entity
ControlInfoMap was indexed by a numerical id and stored in a map.
Now that the IPA interface allows to specify parameters by name, drop the
map and send the sensor's control info map only.
If we'll need more ControlInfoMap to be shared with the IPA, a new parameter
can be added to IPAConfigInfo.
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
The utils.h header #include is separate from the rest of the group for
no reason. Move it to where it should be.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
|
|
When the libcamera project was started, we had no public git tree hosted
on git.libcamera.org. The problem has been addressed a while ago, and
the git.linuxtv.org libcamera repository is now a mirror of the main git
tree. The mirror is useful to benefit from the linuxtv.org automated
compile tests, but it can also confuse users who don't know where the
official version is. To try and clarify this, use the git.libcamera.org
URL consistently through the project.
This doesn't void the validatity of the linuxtv.org repository which
will continue to mirror the libcamera.org repository.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
|
|
Returning a non-managed pointer can cause leaks. Use a unique_ptr<>
instead to avoid possible future issues.
The std::move() for the planes argument to the FrameBuffer constructor
is dropped as it's misleading. FrameBuffer has no constructor that takes
an rvalue reference to planes, so the vector was copied despite the
move. This only clarifies the intent, no functional change is
introduced.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
|
|
The FrameBuffer class has no constructor that takes an rvalue reference
to planes. The std::move() is thus misleading as a copy will still take
place. Drop it to clarify the code, no functional change is introduced.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
|
|
This patch adds a test to test if multi stream using libcamera's
gstreamer element works.
Test will run only on devices that support multistream capture, eg.,
devices that use IPU3 and raspberrypi pipeline. This was tested on
a Raspberry Pi 4B+.
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>
|
|
As the vimc scaler prevents us from passing v4l2-compliance, skip it
until the fix has been merged. Instead of removing it from the
supported_pipelines list, add an extra check, since we will have the
same construct later when we check for the kernel version.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
In gstreamer, when elements are created, usually a floating [1]
reference is returned which simply means, there is no ownership
transfer (yet). Once can simply check for NULL and return through
an error path, without bothering to clean up. Hence, g_autoptr is
not much of help here.
If the NULL checks have been passed successfully, elements are ready
to use. However, we must claim ownership/reference it before using
them via g_object_ref_sink().
This patch build upon this principle and removes the g_autoptr
from gstreamer test base class (gstreamer_test.cpp) whereever
necessary to tide up the code.
[1] https://gstreamer.freedesktop.org/documentation/additional/design/MT-refcounting.html?gi-language=c#refcounting1
Signed-off-by: Vedant Paranjape <vedantparanjape160201@gmail.com>
Signed-off-by: Umang Jain <umang.jain@ideasonboard.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>
|
|
Simplify memory handling and complexity of the test by using
gst_parse_bin_from_description_full [1].
[1]: https://gstreamer.freedesktop.org/documentation/gstreamer/gstutils.html?gi-language=c#gst_parse_bin_from_description_full
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 test hold a valid reference to convert0_ and sink0_ but
not released. This results in a memory leak and can be checked
via valgrind. Drop the references with test cleanup() virtual
function.
Valgrind log (glib and gst suppression files were used):
==345380== LEAK SUMMARY:
==345380== definitely lost: 1,688 bytes in 2 blocks
==345380== indirectly lost: 7,069 bytes in 42 blocks
The patch fixes the leaks reported by valgrind above to:
==348870== LEAK SUMMARY:
==348870== definitely lost: 0 bytes in 0 blocks
==348870== indirectly lost: 0 bytes in 0 blocks
Signed-off-by: Vedant Paranjape <vedantparanjape160201@gmail.com>
Signed-off-by: Umang Jain <umang.jain@ideasonboard.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 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 RGB and YUV conversion doesn't take the stride into account, neither
when creating the textures, nor when sampling them. Fix it by using the
stride as the texture width, and multiplying the x coordinate in the
vertex shaders by a factor to only sample the active portion of the
image.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
|
|
Add support for the YUV420, YVU420 and YUV422 formats supported by
libcamera. YUV420 can be produced by the Raspberry Pi pipeline handler,
being able to display it is useful for testing.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
|
|
To prepare for fully-planar YUV support, rename the existing format
families YUV and NV to YUVPacked and YUVSemiPlanar respectively.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
|
|
Make the stride configurable to support conversion of images with
padding at the end of lines.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
|
|
qcam currently assumes that no padding is used at end of lines, and uses
the image width as the stride. This leads to rendering failures with
some formats on some platforms. To prepare for stride support, add a
stride parameter to the ViewFinder::setFormat() function to pass the
stride from the stream configuration to the viewfinder.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
|
|
An Android HAL client may request multiple identical streams. It is
redundant that a native camera device produces a separate stream for
each of the identical requests. Configure the camera with a single
stream in that case. The other identical HAL streams will be produced by
the YUV post-processor.
Signed-off-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
CameraStream creates PostProcessorYuv if the destination format
is NV12.
Signed-off-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
CameraStream creates PostProcessor and FrameBufferAllocator in
the constructor. CameraStream assumes that a used post processor
is JPEG post processor. Since we need to support various post
processors, we would rather move the creation to configure() so
as to return an error code if no proper post processor is found.
This also moves FrameBufferAllocator and Mutex creation for
consistency.
Signed-off-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Rectify variable renaming style for YPlaneSize, UVPlaneSize.
libcamera uses camelCase where first letter should be in lower case.
Fixes: e355ca0087cd9("android: jpeg: Split and pass the thumbnail planes to encoder")
Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
YUV post-processor doesn't need any instance reference from CameraDevice
class. Remove it.
Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
|
