From patchwork Fri Dec 6 16:07:38 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jacopo Mondi X-Patchwork-Id: 22226 Return-Path: X-Original-To: parsemail@patchwork.libcamera.org Delivered-To: parsemail@patchwork.libcamera.org Received: from lancelot.ideasonboard.com (lancelot.ideasonboard.com [92.243.16.209]) by patchwork.libcamera.org (Postfix) with ESMTPS id 9C79BBE173 for ; Fri, 6 Dec 2024 16:07:57 +0000 (UTC) Received: from lancelot.ideasonboard.com (localhost [IPv6:::1]) by lancelot.ideasonboard.com (Postfix) with ESMTP id 6FF5167E21; Fri, 6 Dec 2024 17:07:56 +0100 (CET) Authentication-Results: lancelot.ideasonboard.com; dkim=pass (1024-bit key; unprotected) header.d=ideasonboard.com header.i=@ideasonboard.com header.b="b0EFEzS7"; dkim-atps=neutral Received: from perceval.ideasonboard.com (perceval.ideasonboard.com [213.167.242.64]) by lancelot.ideasonboard.com (Postfix) with ESMTPS id C5EA8618B3 for ; Fri, 6 Dec 2024 17:07:54 +0100 (CET) Received: from ideasonboard.com (93-61-96-190.ip145.fastwebnet.it [93.61.96.190]) by perceval.ideasonboard.com (Postfix) with ESMTPSA id 053CE641; Fri, 6 Dec 2024 17:07:24 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com; s=mail; t=1733501245; bh=P6JaGOW/mirczEKkAgOcOKQMzd2RG3A1zeS7xB6PFbs=; h=From:To:Cc:Subject:Date:From; b=b0EFEzS7jWJ/kz0K8mgPZ0AZFsdeY7A1AVboPtHUxQnrqfy2IWHIUyCl6ZLiCjkUM 1si0uCk23x6zWaPt7Yvq7PxbIbCkB4CV2VWg+QcwOZAV+XvCvZo+Ukk/RiVVf6260Q Y3CnS9Hedi81UG1F0FAZiwey3HNI29SlkrP4+sCU= From: Jacopo Mondi To: libcamera-devel@lists.libcamera.org Cc: Jacopo Mondi , Harvey Yang , Han-Lin Chen Subject: [PATCH 0/8] libcamera: Support partial metadata completion Date: Fri, 6 Dec 2024 17:07:38 +0100 Message-ID: <20241206160747.97176-1-jacopo.mondi@ideasonboard.com> X-Mailer: git-send-email 2.47.1 MIME-Version: 1.0 X-BeenThere: libcamera-devel@lists.libcamera.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: libcamera-devel-bounces@lists.libcamera.org Sender: "libcamera-devel" There has been quite some back and forth on how this should be done, specifically how to have pipeline handlers behave uniformly and how to have them use the same mechanism to signal metadata availability and store the metadata in Request::metadata() for existing applications to access it. I took the shortest paths: all pipeline handlers now use early metadata completion, but the feature is totally opt-in for applications. The basic idea is to restrict access to Request::metadata() to get a const reference. This way pipeline handlers and applications cannot modify the metadata list directly. Then two new helpers have been added to PipelineHandler base for pipeline handlers to add metadata results to Request::metadata(). These new functions trigger the Camera::metadataAvailable signal from the core. So now all pipeline handlers: 1) To store metadata have to use PipelineHandler::metadataAvailable() function 2) The core triggers Camera::metadataAvailable on behalf of pipelines Performances: - Controls are copied, this is bad as they can transport large quantity of data To avoid sending large quantity of data over a signal, and have the same data stored in Request::metadata, the new signal transports pointers to the ControlId that have been updated. Application can access the actual values from Request::metadata() using the ids. - Avoid intermediate copies when calling PipelineHandler::metadataAvailable() Currently pipeline handlers either - Merge ControlList in Request::metadata() - Set single controls in Request::metadata() Merging ControlList was already non-efficient, as control values have been first copied to a list, then merged (copied) into Request::metadata. The new PipelineHandler::metadataAvailable(Request *, const ControlList &) doesn't introduce any additional copy. When it comes to setting single controls, the easier way would have been to use a ControlValue as in PipelineHandler::metadataAvailable(Request *, ControlId *, ControlValue &) However creating a ControlValue would first copy the control content in the temporary object, and the copy it again when setting it in Request::metadata(). To avoid double copies two templated functions have been prepared and the function arguments are copied directly into Request::metadata(). If I got this right the new metadataAvailable(request, controls::SomeControl, { .... }); is not less efficient than request->metadata().set(controls::SomeControl, { ..... }); Last patch as DNI to show how the new signal can be used by applications. Thanks j Jacopo Mondi (8): libcamera: camera: Introduce metadataAvailable signal guides: application: Document Camera::metadataAvailable libcamera: pipeline_handler: Add metadataAvailable() function guides: pipeline_handler: Document PipelineHandler::metadataAvailable libcamera: request: Add function to reset metadata libcamera: pipelines: Use the metadataAvailable() function libcamera: request: Make access to metadata() const [DNI] apps: cam: Use Camera::metadataAvailable signal .../guides/application-developer.rst | 8 ++ Documentation/guides/pipeline-handler.rst | 26 +++++-- include/libcamera/camera.h | 2 + include/libcamera/internal/pipeline_handler.h | 41 ++++++++++ include/libcamera/internal/request.h | 8 ++ include/libcamera/request.h | 4 +- src/apps/cam/camera_session.cpp | 17 +++++ src/apps/cam/camera_session.h | 2 + src/libcamera/camera.cpp | 42 +++++++++++ src/libcamera/pipeline/imx8-isi/imx8-isi.cpp | 6 +- src/libcamera/pipeline/ipu3/ipu3.cpp | 14 ++-- src/libcamera/pipeline/rkisp1/rkisp1.cpp | 8 +- .../pipeline/rpi/common/pipeline_base.cpp | 12 +-- src/libcamera/pipeline/rpi/vc4/vc4.cpp | 2 +- src/libcamera/pipeline/simple/simple.cpp | 4 +- src/libcamera/pipeline/uvcvideo/uvcvideo.cpp | 4 +- src/libcamera/pipeline/vimc/vimc.cpp | 4 +- src/libcamera/pipeline/virtual/virtual.cpp | 3 +- src/libcamera/pipeline_handler.cpp | 74 +++++++++++++++++++ 19 files changed, 243 insertions(+), 38 deletions(-) --- 2.47.1