From patchwork Fri Oct 4 11:55:53 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: David Plowman X-Patchwork-Id: 21512 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 DEAB0BD80A for ; Fri, 4 Oct 2024 11:56:11 +0000 (UTC) Received: from lancelot.ideasonboard.com (localhost [IPv6:::1]) by lancelot.ideasonboard.com (Postfix) with ESMTP id B58B76352C; Fri, 4 Oct 2024 13:56:06 +0200 (CEST) Authentication-Results: lancelot.ideasonboard.com; dkim=pass (2048-bit key; unprotected) header.d=raspberrypi.com header.i=@raspberrypi.com header.b="dN8Y26yz"; dkim-atps=neutral Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [IPv6:2a00:1450:4864:20::435]) by lancelot.ideasonboard.com (Postfix) with ESMTPS id 898FB62C8F for ; Fri, 4 Oct 2024 13:56:03 +0200 (CEST) Received: by mail-wr1-x435.google.com with SMTP id ffacd0b85a97d-37cca239886so1274633f8f.2 for ; Fri, 04 Oct 2024 04:56:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raspberrypi.com; s=google; t=1728042963; x=1728647763; 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=/+QeznJmVtfJhdoE5niV18EGr1SvQlkkgJ2zxe7NDGY=; b=dN8Y26yzt5WjmV3vtX6+wWAWwaIjeMxzxqYUcdDZSlqyJdfKzlNeTuJYJOXXXBVpY7 6yhrFf3U3VuWPIskENVscuhkRl5hLFfxuCuPrL8LMFoVOr9XPTiZQKQSTpTAF+wv2CN6 Qp9Q6KnsjQ4i99JK3fkJVrAIttnQvNYOrY+XbVqtylTT/vnBC6+YtbFn4g58oA++xw5b XJ+SmLGOnZ1LF8QERzII5rd24zWdovadvkCbhkRgGIRLdBYFZlY72s1pPdwQDBJ7KdDQ 8WkmNtV5bRi21En4YBYsTNRtd5VCa0CKAy86LWUm4Eu4/JgFtHu9Zpqa6BeNjNe0cee9 91xw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1728042963; x=1728647763; 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=/+QeznJmVtfJhdoE5niV18EGr1SvQlkkgJ2zxe7NDGY=; b=ZhpNTEHvVwwNvSVe/hru7mC0xvLbjwYgXPPisclU2wkqX7M5rPdQqcBpIEszz/4HuK rOGwN7/hMkS4OkJTWrqmeBgrEA+MpVPv+2CkJ/ygD1bb0xfRbwlTiFgvNGOm8MBRAPSW tfSSCYdyekslmUmFPC6kwvEy63jNb+cI3WhT85TfBm3pcAmagPIItc/vFPXo8r4RgLnH rrq1VS5xTSC4oPpAOiwsAdmZTMbGjU+mWwaojvdO/GV74uoawe7NpcOL/yhHOC0jM54U nQSb7bismNt9jO3yUf3vuBnq6WQS14MtLHRsbP7tyO4wYe7SSLR4JYSyU49jfStNG9Hk K+ww== X-Gm-Message-State: AOJu0YwRC6Pe7aUGTuAQl8NDd5yHfXo8wvOYzGfKqbcEa5VHrp/bSmI3 lN5+DIdPM1bRajmwDbDYppvPwAa+pAIv5bI6asMloV0As4X+0cfGgzWVDBemWaL1jXpue/mcVFL U X-Google-Smtp-Source: AGHT+IGjx0fS5C7bqF5N73ZKjOKeyVP4nzVMjBqPgZBJgDMLhh1GbZFL4SOIQS4Yj8q/aJdRBuTelQ== X-Received: by 2002:a5d:64c8:0:b0:368:5ba0:622 with SMTP id ffacd0b85a97d-37d0eafa3a2mr2132091f8f.44.1728042962696; Fri, 04 Oct 2024 04:56:02 -0700 (PDT) Received: from raspberrypi.pitowers.org ([2a00:1098:3142:1f:daa2:371b:a97:3e3e]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-37d081f743esm3107147f8f.21.2024.10.04.04.56.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 04 Oct 2024 04:56:02 -0700 (PDT) From: David Plowman To: libcamera-devel@lists.libcamera.org Cc: David Plowman , Arsen Mikovic , Naushir Patuck Subject: [PATCH 1/6] controls: rpi: Add controls for the camera sync algorithm Date: Fri, 4 Oct 2024 12:55:53 +0100 Message-Id: <20241004115558.9166-2-david.plowman@raspberrypi.com> X-Mailer: git-send-email 2.39.5 In-Reply-To: <20241004115558.9166-1-david.plowman@raspberrypi.com> References: <20241004115558.9166-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" The camera sync algorithm uses the following new controls: SyncMode - a camera can be a server or client SyncWait - whether the sync point has been reached SyncLag - how far away from synchronisation a camera was SyncFrameWallClock - for passing wall clock time to the IPA. Signed-off-by: David Plowman Signed-off-by: Arsen Mikovic Reviewed-by: Naushir Patuck --- src/libcamera/control_ids_rpi.yaml | 76 ++++++++++++++++++++++++++++++ 1 file changed, 76 insertions(+) diff --git a/src/libcamera/control_ids_rpi.yaml b/src/libcamera/control_ids_rpi.yaml index 42c4bf5d..b5605dfa 100644 --- a/src/libcamera/control_ids_rpi.yaml +++ b/src/libcamera/control_ids_rpi.yaml @@ -30,4 +30,80 @@ controls: \sa StatsOutputEnable + - FrameWallClock: + type: int64_t + description: | + Control that returns the wall clock timestamp of a frame. This + is the "time since epoch" value obtained from the system, in + microseconds. This value is likely to be subject to + significantly more jitter than the recorded SensorTimestamp. + + - SyncMode: + type: int32_t + description: | + Puts the camera system into sync mode, so that frames can be + temporally synchronised with another camera, either on the same + device, or on a different one. + enum: + - name: SyncModeOff + value: 0 + description: Sync not in use. + - name: SyncModeServer + value: 1 + description: | + Sync on, 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: | + Sync on, 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. + + - SyncWait: + type: bool + description: | + When using the camera syncrhonisation algorithm, the server + broadcasts timing information to the client. This also includes + the time (some number of frames in the future) at which it will + tell the application running on the server when to start using + the image frames (the "ready time"). + + The client receives the "ready time" from the server, and will + tell the application on its end to start using the frames at + this same moment. + + While this control value is true, applications (on both client + and server) should continue to wait. + + Once this value is false, it means that this is the frame where + client and server have agreed that it is the first synchronised + frame that should be used by the application. + + - SyncLag: + type: int64_t + description: | + The lag is the amount of time since the "ready time", at which + the server and client will signal their controlling applications + that the frames are now synchronised and should be used. + + Normally, therefore, the value will start negative (the "ready + time" is in the future), and increase towards zero, before + becoming positive (the "ready time" has elapsed). + + Servers always report this value; clients will omit this control + until they have received a message from the server that enables + them to calculate it. + + Normally there will be just one frame where the lag value is, or + is very close to, zero - the one for which SyncWait becomes + false. But note that if frames are being dropped, then the "near + zero" value, or indeed any other, could be skipped. In these + cases the lag value allows an application to work out exactly + what has happened. + + \sa SyncWait ...