| Age | Commit message (Collapse) | Author |
|---|
|
Implement support for the new '--metadata' option by printing the
value of each metadata entry associated with a completed Request.
As sample of the output, running on raspberry pi, looks like the
following:
3050.205672 (30.01 fps) stream0 seq: 000033 bytesused: 720000
ScalerCrop = (0x2)/3280x2460
ExposureTime = 13969
AeLocked = true
DigitalGain = 1.000721
Lux = 771.204224
ColourGains = [ 1.561101, 1.629698 ]
ColourTemperature = 4289
SensorBlackLevels = [ 4096, 4096, 4096, 4096 ]
ColourCorrectionMatrix = [ 1.691066, -0.599756, -0.091317, -0.437452, 1.983766, -0.546314, -0.083429, -0.722407, 1.805836 ]
AnalogueGain = 2.000000
SensorTimestamp = 3050205672000
3050.238999 (30.01 fps) stream0 seq: 000034 bytesused: 720000
ScalerCrop = (0x2)/3280x2460
ExposureTime = 13969
AeLocked = true
DigitalGain = 1.000709
Lux = 771.232422
ColourGains = [ 1.560868, 1.630029 ]
ColourTemperature = 4289
SensorBlackLevels = [ 4096, 4096, 4096, 4096 ]
ColourCorrectionMatrix = [ 1.691081, -0.599726, -0.091362, -0.437497, 1.983627, -0.546130, -0.083420, -0.722523, 1.805943 ]
AnalogueGain = 2.000000
SensorTimestamp = 3050238999000
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
The cam option --capture=N is suppose to only capture N requests. But if
the processing done for each request is large (such as writing it to a
slow disk) the current implementation could queue more than N requests
before the exit condition is detected and capturing stopped.
Solve this by only queueing N requests while still waiting for N
requests to complete before exiting.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
The request completion handler is invoked in the camera manager thread,
which shouldn't be blocked for large amounts of time. As writing the
frames to disk can be a time-consuming process, move request processing
to the main thread by queueing an event to the event loop.
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>
|
|
Initialize last_ to 0 to avoid uninitialized use.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@iki.fi>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Signed-off-by: Kieran Bingham <kieran.bingham@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>
|
|
Print the timestamp of the captured buffer in addition to the frame
rate, as this is more precise information that can help debugging issue.
The log changes from
Using camera \_SB_.PCI0.XHC_.RHUB.HS05-5:1.0-0bda:58f4
Capture until user interrupts by SIGINT
fps: 0.00 stream0 seq: 000000 bytesused: 169968
fps: 28.57 stream0 seq: 000002 bytesused: 170352
fps: 31.25 stream0 seq: 000003 bytesused: 170428
fps: 32.26 stream0 seq: 000004 bytesused: 170672
fps: 27.78 stream0 seq: 000005 bytesused: 170568
to
Using camera \_SB_.PCI0.XHC_.RHUB.HS05-5:1.0-0bda:58f4
Capture until user interrupts by SIGINT
93473.942525 (0.00 fps) stream0 seq: 000000 bytesused: 183940
93474.006528 (15.62 fps) stream0 seq: 000002 bytesused: 183512
93474.038525 (31.25 fps) stream0 seq: 000003 bytesused: 183760
93474.074530 (27.77 fps) stream0 seq: 000004 bytesused: 182704
93474.106581 (31.20 fps) stream0 seq: 000005 bytesused: 182768
While at it, compute the frame rate on the buffer timestamps instead of
sampling the clock in the request completion handler.
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>
|
|
The Stream pointer just acts as a key in the Request object. There is no
good use-case to modify a stream from a pointer retrieved from the
Request, make it const. This allows pipeline handlers to better express
that the Stream pointer is retrieved in a Request should just be treated
as a key.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Declare a using directive for the map of Stream to FrameBuffer. Update
all users of Request::buffers() to use the new usage directive.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Extend the '--capture' option with and optional numerical argument to be
able to specify how many frames to capture before exiting. If the
optional argument is not provided the old behavior of running until the
user interrupts with a SIGINT is retained.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Prepare for the ability to exit the event loop based on conditions in
the request complete handler by caching the pointer instead of passing
it as an argument.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
The Camera class currently requires the allocator to have no allocated
buffer before the camera is reconfigured, and the allocator to be
destroyed before the camera is released. There's no basis for these
restrictions anymore, remove them.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
|
|
The stream in the stream configuration is not filled in before we
configure the camera, move the generating and caching of names after the
configuration.
Without this fix writing multiple streams to disk overwrites the frames
as the filenames are not unique.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
With the FrameBuffer rework completed there is no reason to keep the
camera prepared state around as buffer allocations are now decoupled
from the camera state. Remove the camera state simplifying the API.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
With the buffer allocator in use it's possible to cache the dmabuf
memory mappings when starting the camera instead of mapping and
unmapping them each time.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Switch to the FrameBuffer interface where all buffers are treated as
external buffers and are allocated outside the camera. Applications
allocating buffers using libcamera are switched to use the
FrameBufferAllocator helper.
Follow-up changes to this one will finalize the transition to the new
FrameBuffer interface by removing code that is left unused after this
change.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Move the metadata retrieved when dequeuing a V4L2 buffer into a
FrameMetadata object. This is done as a step to migrate to the
FrameBuffer interface as the functions added to Buffer around
FrameMetadata match the ones in FrameBuffer.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
In the FrameBuffer interface the stream will not be available from the
buffer object as the buffer might be allocated externally. The
application needs to explicitly state which stream the buffer is being
added for to the request.
Extend the addBuffer() function to get this information explicitly from
the caller.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
The buffer index is a V4L2 concept that will be hidden from users with
the introduction of a new FrameBuffer class. In preparation for this,
remove the index from log messages.
Keep and move one debug log message where the index is available as the
V4L2 buffer is being dequeued for the video device and it's useful when
debugging.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Do not store the camera raw pointer in the capture class, this will
prevent forwarding the shared pointer in the future.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
signal
The stream to buffer map in the requestCompleted signal is taken
directly from the request which is part of the same signal. Remove the
map as it can be fetched directly from the request.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Remove unused local map variable.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Now that our usage of C compatibility header is documented, use them
consistently through the source code.
While at it, group the C and C++ include statements as defined in the
coding style, and fix a handful of #include ordering issues.
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>
|
|
Replace the clock_gettime()-based API with durations expressed as
integers with the std::chrono API.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
|
|
Buffer instances reference memory, which is modelled internally by a
BufferMemory instance. Store a pointer to the BufferMemory in the Buffer
class, and populate it when the buffer is queued to the camera through a
request. This is useful for applications to access the buffer memory in
the buffer or request completion handler.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
|
|
All interactions with the Stream's buffers currently go through the
BufferPool. In order to shorten accessing the buffers array, and eventually
restrict access to the Stream's internal buffer pool, provide operations to
access, create and destroy buffers.
It is still possible to access the pool for pipeline handlers to
populate it by exporting buffers from a video device to Stream's pool.
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
|
|
The cam and qcam applications, as well as the camera capture test case,
access the Stream::bufferPool in order to know how many requests to
initially queue. As part of an effort to remove access to the buffer
pool from applications, use the buffer count from the stream
configuration instead.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
|
|
The Buffer class is a large beast the stores information about the
buffer memory, dynamic metadata related to the frame stored in the
buffer, and buffer reference data (in the index). In order to implement
buffer import we will need to extend this with dmabuf file descriptors,
making usage of the class even more complex.
Refactor the Buffer class by splitting the buffer memory information to
a BufferMemory class, and repurposing the Buffer class to reference a
buffer and to store dynamic metadata. The BufferMemory class becomes a
long term storage, valid and stable from the time buffer memory is
allocated to the time it is freed. The Buffer class, on the other hand,
becomes transient, is created on demand when an application requires a
buffer, is given to a request, and is deleted when the request
completes.
Buffer and BufferMemory don't need to be copied, so their copy
constructor and assignment operators are deleted.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
|
|
queueRequest() is called after starting the stream.
If it fails, the stream should be stopped, otherwise it can get a
"Device or resource busy" error, due to VIDIOC_REQBUFS ioctls being
called after VIDIOC_STREAMON without VIDIOC_STREAMOFF in-between.
Signed-off-by: Helen Koike <helen.koike@collabora.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Most of the camera configuration preparation that is done in the
Capture module is not specific to capturing and could be useful for
other modules. Extract the generic parts to CamApp and do basic
preparation of the configuration before passing it to modules.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Reduce the complexity of main.cpp by compartmentalising the capture
logic into its own class. There is no functional change.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
