From patchwork Wed Dec 18 18:03:10 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: David Plowman X-Patchwork-Id: 22401 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 0D2CAC3306 for ; Wed, 18 Dec 2024 18:03:25 +0000 (UTC) Received: from lancelot.ideasonboard.com (localhost [IPv6:::1]) by lancelot.ideasonboard.com (Postfix) with ESMTP id 047FB680B2; Wed, 18 Dec 2024 19:03:24 +0100 (CET) Authentication-Results: lancelot.ideasonboard.com; dkim=pass (2048-bit key; unprotected) header.d=raspberrypi.com header.i=@raspberrypi.com header.b="ZWbFTrII"; dkim-atps=neutral Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [IPv6:2a00:1450:4864:20::32b]) by lancelot.ideasonboard.com (Postfix) with ESMTPS id DCF70680A2 for ; Wed, 18 Dec 2024 19:03:19 +0100 (CET) Received: by mail-wm1-x32b.google.com with SMTP id 5b1f17b1804b1-436249df846so47462965e9.3 for ; Wed, 18 Dec 2024 10:03:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raspberrypi.com; s=google; t=1734544999; x=1735149799; darn=lists.libcamera.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=a34Z2mQqo6HWxuMMY6rFsnAumW5AmxjBsIlATHxwa6E=; b=ZWbFTrIIThmceZf7LlTOneW0sIXVWYLI4+hH7khMR8394KCkzJ5ZVi4I+0vqa7A6D8 Cx61h8NXd5j5G16Rzd0Ba08kX/2KnFjmg7IKcB9HjvHrjuJzvu7ccvB/tooVCFe9TqXb f/y02UV7GDDnUMmwT6i7p97AtMtIqDBr0Y4kZnIaLSnqLH/+NHbWd3O9siCbDNhCdbEk JhRILxAtSc/z+zY1c6aQAnpbjvbG+LRksQ2fOADP6dgKzYpLJw+mRc0HdY4uTTe3rzyX jvO8ow2zc9bY97jK7RoXwcrk23ThcbY395ETqCWl7G+tZhIV9WqfbfvU1aq+nStHLNdr p0EQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1734544999; x=1735149799; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=a34Z2mQqo6HWxuMMY6rFsnAumW5AmxjBsIlATHxwa6E=; b=LftXvkmXWIGcGsABowoValkJUUyGLFv+/mVvk9r2jkpjx6IDf6Q9Oe+6WLoyN3zO8u L858hmppw+k8PViWm16UeJu/F2sRlgj94fnRdxWIt7zut27eXGepczNUYCRuFZ6eMx7D CFi4EIA++lMbR3JHqfy7Pmv4gF/RF48+mFi7cqooTXaiva/kIBrn1IKGKLSf9aFNxAS4 5va4ih6xUXN99cyuqUWY/XYYrd+pRGyg1SB4UjGjHveyAK5PQ5bbfNSy8PXZ6hdnp6ym GYAqcjy7iL3djpcvViVQkQ8oN5/r7jbfbHUyJ401g7bZLPs5NjJzmx6+s+NiRvLZY54Z NSdQ== X-Gm-Message-State: AOJu0YzlWzg0Z42HNbivQpwyYV/3pVCx2KJhLqMpB8cinujA0QlymjD3 Yeg01JizWkxM/foXxXkEf0foB/KY9IGrUQnup7weohAnNRkeFsltgp+0U3JVZp6ldfP6DTTY+hN s X-Gm-Gg: ASbGncu7MicWzGzkcTuTrEqvzzedsU55Scy+hTkCIJuayzPUPzUrcrFekJhIrplHJjH 0iD89Ru2rIrhPlWG7dcvUf5T4fH1ItaFfgwoyTl0qsLkpmMbcjLt3493Ww0DKmTcOGKyo8uW2LM lGwf3FC6iTjmcY9O9Q9SFfM+OolLGFrXKlASgvY4Cr0CJBAkzzNHpocPZtOoEaXUaucxK3ZPTVW XoQvKNXkce4PlBzEMqIypyL/UC5B85iEcgg5qHHCanG0kVIoD2nYRK0jrlfrsgjTmdvD+1/V9w6 3fqgN1Ey/NhO X-Google-Smtp-Source: AGHT+IEKmxBmx+hLTo1JCDz8CxHKYx3Zp20fMcF3FPJu+dG7jwOiamkKJ7vGc/lOEgawGggH3bO3rQ== X-Received: by 2002:a05:600c:1d15:b0:436:46f9:4fc6 with SMTP id 5b1f17b1804b1-4365c78124fmr2228985e9.8.1734544998786; Wed, 18 Dec 2024 10:03:18 -0800 (PST) Received: from raspberrypi.pitowers.org ([2a00:1098:3142:1f:c68a:6be1:5ba3:eddd]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-43656b01c88sm27927285e9.17.2024.12.18.10.03.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 18 Dec 2024 10:03:16 -0800 (PST) From: David Plowman To: libcamera-devel@lists.libcamera.org Cc: David Plowman , Naushir Patuck Subject: [PATCH v2 3/3] controls: Add camera synchronisation controls Date: Wed, 18 Dec 2024 18:03:10 +0000 Message-Id: <20241218180310.7824-4-david.plowman@raspberrypi.com> X-Mailer: git-send-email 2.39.5 In-Reply-To: <20241218180310.7824-1-david.plowman@raspberrypi.com> References: <20241218180310.7824-1-david.plowman@raspberrypi.com> 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" New controls are added to control the camera "sync" algorithm, which allows different cameras to synchronise their frames. Signed-off-by: David Plowman Reviewed-by: Naushir Patuck --- src/libcamera/control_ids_core.yaml | 109 ++++++++++++++++++++++++++++ 1 file changed, 109 insertions(+) diff --git a/src/libcamera/control_ids_core.yaml b/src/libcamera/control_ids_core.yaml index 8485f7e8..cf502944 100644 --- a/src/libcamera/control_ids_core.yaml +++ b/src/libcamera/control_ids_core.yaml @@ -1027,4 +1027,113 @@ controls: The FrameWallClock control can only be returned in metadata. + - SyncMode: + type: int32_t + description: | + Enable or disable camera synchronisation ("sync") mode. + + When sync mode is enabled, a camera will synchronise frames temporally + with other cameras, either attached to the same device or a different + one. There should be one "server" device, which broadcasts timing + information to one or more "clients". Communication is one-way, from + server to clients only, and it is only clients that adjust their frame + timings to match the server. + + Sync mode requires all cameras to be running at (as far as possible) the + same fixed framerate. Clients may continue to make adjustments to keep + their cameras synchronised with the server for the duration of the + session, though any updates after the initial ones should remain small. + + \sa SyncReady + \sa SyncTimer + \sa SyncFrames + + enum: + - name: SyncModeOff + value: 0 + description: Disable sync mode. + - name: SyncModeServer + value: 1 + description: | + Enable sync mode, act as server. The server broadcasts timing + messages to any clients that are listening, so that the clients can + synchronise their camera frames with the server's. + - name: SyncModeClient + value: 2 + description: | + Enable sync mode, act as client. A client listens for any server + messages, and arranges for its camera frames to synchronise as + closely as possible with the server's. Many clients can listen out + for the same server. Clients can also be started ahead of any + servers, causing them merely to wait for the server to start. + + - SyncReady: + type: bool + description: | + When using the camera synchronisation algorithm, the server broadcasts + timing information to the clients. This also includes the time (some + number of frames in the future, called the "ready time") at which the + server will signal its controlling application, using this control, to + start using the image frames. + + The client receives the "ready time" from the server, and will signal + its application to start using the frames at this same moment. + + While this control value is false, applications (on both client and + server) should continue to wait, and not use the frames. + + Once this value becomes true, it means that this is the first frame + where the server and its clients have agreed that they will both be + synchronised and that applications should begin consuming frames. + Thereafter, this control will continue to signal the value true for + the rest of the session. + + \sa SyncMode + \sa SyncTImer + \sa SyncFrames + + - SyncTimer: + type: int64_t + description: | + This reports the amount of time, in microseconds, until the "ready + time", at which the server and client will signal their controlling + applications that the frames are now synchronised and should be + used. The value may be refined slightly over time, becoming more precise + as the "ready time" approaches. + + Servers always report this value, whereas clients will omit this control + until they have received a message from the server that enables them to + calculate it. + + Normally the value will start positive (the "ready time" is in the + future), and decrease towards zero, before becoming negative (the "ready + time" has elapsed). So there should be just one frame where the timer + value is, or is very close to, zero - the one for which the SyncReady + control becomes true. At this moment, the value indicates how closely + synchronised the client believes it is with the server. + + But note that if frames are being dropped, then the "near zero" valued + frame, or indeed any other, could be skipped. In these cases the timer + value allows an application to deduce that this has happened. + + \sa SyncMode + \sa SyncReady + \sa SyncFrames + + - SyncFrames: + type: int32_t + description: | + The number of frames the server should wait, after enabling + SyncModeServer, before signalling (via the SyncReady control) that + frames should be used. This therefore determines the "ready time" for + all synchronised cameras. + + This control value should be set only for the device that is to act as + the server, before or at the same moment at which SyncModeServer is + enabled. + + \sa SyncMode + \sa SyncReady + \sa SyncTimer + ...