| Age | Commit message (Collapse) | Author |
|---|
|
Rename the BufferWriter class to FileSink to establish a common naming
scheme for all sinks.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
|
|
Make the BufferWriter class inherit from FrameSink, and use the
FrameSink API to manage it. This makes the code more generic, and will
allow usage of other sinks.
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>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
|
|
To allow testing capture from multiple cameras concurrently, turn the
--camera option into an array option, and create one CameraSession per
specified camera. The code is adapted to iterate over the sessions
vector instead of handling a single session. Thanks to all the
refactoring previously performed, changes are minimal.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
To prepare for multi-camera support, extend the file naming scheme for
captured frames to include the camera index in addition to the stream
name and frame number.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Use the new hierarchical options feature of the option parser to turn
camera-related option (--capture, --file, --stream, --strict-formats and
--metadata) into children of the --camera option. As an added bonus, we
don't need to check anymore if a camera has been specified when capture
is requested, as that's now enforced by the option parser.
This change prepares for support of multiple cameras.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
The three CamApp functions listControls(), listProperties() and
infoConfiguration() operate on a camera. They would thus be better
placed in the CameraSession class. Move them there. As they now have no
error to return anymore, make them void functions.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Continue moving towards making the CameraSession class the central point
to handle a camera by moving the camera acquire operation. A new
CameraSession::camera() function is needed to allow access to the camera
from CamApp.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Creating a configuration for a camera is an operation that logically
belongs to the CameraSession class. Move it there.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Move the local CameraSession variable from the CamApp::run() function to
a member variable of the CamApp class, created in CamApp::init(). This
is a first step towards moving code to the CameraSession class.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Store the BufferWriter and FrameBufferAllocator pointers in
std::unique_ptr<> instances to simplify memory management and avoid
leaks.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
To prepare for multiple concurrent camera sessions, move the event loop
exec() call from the CameraSession class to the CamApp class.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Make exiting the event loop the responsibility of the application, not
the camera session, to prepare for support of multiple camera sessions.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Don't pass the event loop to the CameraSession constructor, as passing
this global object explicitly isn't a design that can scale.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Rename the Capture class to CameraSession, to prepare for multi-camera
support that will gather more camera-related operations than capture in
that class.
While at it, remove an unneeded blank line.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
