[{"id":12193,"web_url":"https://patchwork.libcamera.org/comment/12193/","msgid":"","date":"2020-08-28T12:59:05","subject":"Re: [libcamera-devel] [PATCH] libcamera: buffer: Improve timestamp\n\tdocumentation","submitter":{"id":1,"url":"https://patchwork.libcamera.org/api/people/1/","name":"Umang Jain","email":"email@uajain.com"},"content":"Hi Kieran,\n\nOn 8/28/20 5:25 PM, Kieran Bingham wrote:\n> The Buffer timestamp documentation is short and does not explain that\n> the timestamp is based on a monotonic time source, as opposed to the\n> real/wall-time clocks available in the system.\n>\n> Expand upon the statements to detail that it can not be used directly as\n> a wall-clock for the captured date/time without a further reference\n> point, and that by taking a reference point - the user will be bringing\n> in potential inconsistencies which must be considered.\n>\n> Signed-off-by: Kieran Bingham \n> ---\n> src/libcamera/buffer.cpp | 8 +++++++-\n> 1 file changed, 7 insertions(+), 1 deletion(-)\n>\n> diff --git a/src/libcamera/buffer.cpp b/src/libcamera/buffer.cpp\n> index a094737d0392..c08ca4234b29 100644\n> --- a/src/libcamera/buffer.cpp\n> +++ b/src/libcamera/buffer.cpp\n> @@ -92,7 +92,13 @@ LOG_DEFINE_CATEGORY(Buffer)\n> * The timestamp is expressed as a number of nanoseconds relative to the system\n> * clock since an unspecified time point.\n> *\n> - * \\todo Be more precise on what timestamps refer to.\n> + * This timestamp is monotonic and not affected by changes in system time,\n> + * however it is still susceptible to small adjustments made by NTP.\n> + *\n> + * This clock has no specification on its time base, so can not be directly be\n> + * converted to a 'real' wall clock time without a comparable reference point.\n> + * However, continued conversions from the reference point, may bring in\n> + * inaccuracies due to changes on the real time clock which must be considered.\n> */\n> \n> /**\nWell, I just read clock_gettime manpage a while ago, so that context\nhelps me inferring this documentation more clearly. ;-)\n\nWould it help pointing to that manpage as a \"See also\" for reference?\n\nAnyways,\n\nReviewed-by: Umang Jain ","headers":{"Return-Path":"","X-Original-To":"parsemail@patchwork.libcamera.org","Delivered-To":"parsemail@patchwork.libcamera.org","Received":["from lancelot.ideasonboard.com (lancelot.ideasonboard.com\n\t[92.243.16.209])\n\tby patchwork.libcamera.org (Postfix) with ESMTPS id E9A26BDC71\n\tfor ;\n\tFri, 28 Aug 2020 12:59:09 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id 61DBD628F3;\n\tFri, 28 Aug 2020 14:59:09 +0200 (CEST)","from wrqvntvw.outbound-mail.sendgrid.net\n\t(wrqvntvw.outbound-mail.sendgrid.net [149.72.39.137])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id 34E7E6037B\n\tfor ;\n\tFri, 28 Aug 2020 14:59:06 +0200 (CEST)","by filterdrecv-p3iad2-787bb5c9bc-z28f8 with SMTP id\n\tfilterdrecv-p3iad2-787bb5c9bc-z28f8-18-5F48FF98-DA\n\t2020-08-28 12:59:05.107196263 +0000 UTC m=+68359.488272143","from mail.uajain.com (unknown)\n\tby ismtpd0001p1maa1.sendgrid.net (SG) with ESMTP\n\tid z6Ix776iRnSyryWV72pv4A Fri, 28 Aug 2020 12:59:04.400 +0000 (UTC)"],"Authentication-Results":"lancelot.ideasonboard.com;\n\tdkim=fail reason=\"signature verification failed\" (1024-bit key;\n\tunprotected) header.d=uajain.com header.i=@uajain.com\n\theader.b=\"nq9jDqkB\"; dkim-atps=neutral","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=uajain.com;\n\th=subject:references:from:mime-version:in-reply-to:to:content-type:\n\tcontent-transfer-encoding;\n\ts=s1; bh=Fa40kQ4meJOc7JhMSkysABEobiOgfsanIeAHUHDju7s=;\n\tb=nq9jDqkBwzRg0lXEINhmnRfqLW+ENqD/iCtGADPDAnJC08NomvjPJtGe/EgS7FwSicKG\n\t2ADXIuPRmMhRhQJCxZJDhPRoc5sEKDCHnsbSkNNmhbLDMHFzlBbyHGq36Uslitl3aRIw5q\n\tsBvu+o9MXzG2pijo/0mCpWfBIyrZUTNpQ=","References":"<20200828115507.305323-1-kieran.bingham@ideasonboard.com>","From":"Umang Jain ","Message-ID":"","Date":"Fri, 28 Aug 2020 12:59:05 +0000 (UTC)","Mime-Version":"1.0","In-Reply-To":"<20200828115507.305323-1-kieran.bingham@ideasonboard.com>","X-SG-EID":"1Q40EQ7YGir8a9gjSIAdTjhngY657NMk9ckeo4dbHZDiOpywc/L3L9rFqlwE4KPcytdNsKVIgBmp5SVZAuCwQUGYSou11R2Gy3JQ1Ch56Qtyw5pqR8cU+/1xMmlu2GVnhmfeZj6udq7bQXwpbu5iS/EnuVAFyJ4/DL4iyUZzIMyUEoZmRL5DW02N9fdg+Mh/EUJTkoCgNUKGFlJaTKbx6zy1pWqFN6/UMVxLSWyodE3lUX0hG0FelYvuTE+MgSPbLjPo0YsOAvCRTbDvZCJO2g==","To":"Kieran Bingham , libcamera devel\n\t","Content-Language":"en-US","Subject":"Re: [libcamera-devel] [PATCH] libcamera: buffer: Improve timestamp\n\tdocumentation","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Content-Transfer-Encoding":"7bit","Content-Type":"text/plain; charset=\"us-ascii\"; Format=\"flowed\"","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}},{"id":12196,"web_url":"https://patchwork.libcamera.org/comment/12196/","msgid":"<20200828145941.GA8557@pendragon.ideasonboard.com>","date":"2020-08-28T14:59:41","subject":"Re: [libcamera-devel] [PATCH] libcamera: buffer: Improve timestamp\n\tdocumentation","submitter":{"id":2,"url":"https://patchwork.libcamera.org/api/people/2/","name":"Laurent Pinchart","email":"laurent.pinchart@ideasonboard.com"},"content":"Hi Kieran,\n\nThank you for the patch.\n\n> The Buffer timestamp documentation is short and does not explain that\n> the timestamp is based on a monotonic time source, as opposed to the\n> real/wall-time clocks available in the system.\n> \n> Expand upon the statements to detail that it can not be used directly as\n> a wall-clock for the captured date/time without a further reference\n> point, and that by taking a reference point - the user will be bringing\n> in potential inconsistencies which must be considered.\n> \n> Signed-off-by: Kieran Bingham \n> ---\n> src/libcamera/buffer.cpp | 8 +++++++-\n> 1 file changed, 7 insertions(+), 1 deletion(-)\n> \n> diff --git a/src/libcamera/buffer.cpp b/src/libcamera/buffer.cpp\n> index a094737d0392..c08ca4234b29 100644\n> --- a/src/libcamera/buffer.cpp\n> +++ b/src/libcamera/buffer.cpp\n> @@ -92,7 +92,13 @@ LOG_DEFINE_CATEGORY(Buffer)\n> * The timestamp is expressed as a number of nanoseconds relative to the system\n> * clock since an unspecified time point.\n> *\n> - * \\todo Be more precise on what timestamps refer to.\n> + * This timestamp is monotonic and not affected by changes in system time,\n> + * however it is still susceptible to small adjustments made by NTP.\n> + *\n> + * This clock has no specification on its time base, so can not be directly be\n> + * converted to a 'real' wall clock time without a comparable reference point.\n> + * However, continued conversions from the reference point, may bring in\n> + * inaccuracies due to changes on the real time clock which must be considered.\n\nI'd keep a todo here, as we still haven't decided what clock source is\nthe most suitable. Describing what is being done today is of course a\ngood idea, but one issue is that we get the timestamp directly from\nV4L2, and V4L2 doesn't guarantee what timestamp source is used. I've had\na look at Linus' master branch, and we have, in drivers/media/,\n\n 103 ktime_get\n 6 ktime_get_boottime\n 6 ktime_get_real\n\nktime_get_boottime is only used in DVB, so we're fine there.\nktime_get_real is used by\n\ndrivers/media/pci/ttpci/av7110.c: ktime_get_real_ts64(&ts);\ndrivers/media/rc/streamzap.c: sz->signal_start = ktime_get_real();\ndrivers/media/rc/streamzap.c: sz->signal_start = ktime_get_real();\ndrivers/media/test-drivers/vivid/vivid-rds-gen.c: time64_to_tm(ktime_get_real_seconds(), 0, &tm);\ndrivers/media/test-drivers/vivid/vivid-vbi-gen.c: time64_to_tm(ktime_get_real_seconds(), 0, &tm);\ndrivers/media/usb/uvc/uvc_video.c: return ktime_get_real();\n\nUVC supports selecting either the monotonic or real clock, with the\nmonotonic clock being the default, so I think we're fine too.\n\nWe can thus assume for the time being that we only get CLOCK_MONOTONIC\ntimestamp. Should we simplify the doc by just telling we use\nCLOCK_MONOTONIC, with a todo comment to revisit the topic and possibly\nselect a different clock, or make the clock source configurable ?\n\n> */\n> \n> /**","headers":{"Return-Path":"","X-Original-To":"parsemail@patchwork.libcamera.org","Delivered-To":"parsemail@patchwork.libcamera.org","Received":["from lancelot.ideasonboard.com (lancelot.ideasonboard.com\n\t[92.243.16.209])\n\tby patchwork.libcamera.org (Postfix) with ESMTPS id 04594BF019\n\tfor ;\n\tFri, 28 Aug 2020 15:00:05 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id 8B17A61EA0;\n\tFri, 28 Aug 2020 17:00:04 +0200 (CEST)","from perceval.ideasonboard.com (perceval.ideasonboard.com\n\t[IPv6:2001:4b98:dc2:55:216:3eff:fef7:d647])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id 733C26037B\n\tfor ;\n\tFri, 28 Aug 2020 17:00:02 +0200 (CEST)","from pendragon.ideasonboard.com (62-78-145-57.bb.dnainternet.fi\n\t[62.78.145.57])\n\tby perceval.ideasonboard.com (Postfix) with ESMTPSA id A687E303;\n\tFri, 28 Aug 2020 17:00:01 +0200 (CEST)"],"Authentication-Results":"lancelot.ideasonboard.com;\n\tdkim=fail reason=\"signature verification failed\" (1024-bit key;\n\tunprotected) header.d=ideasonboard.com header.i=@ideasonboard.com\n\theader.b=\"WuRSlOg5\"; dkim-atps=neutral","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com;\n\ts=mail; t=1598626801;\n\tbh=4m2nOXg83J8UbFRvREC91dGnP8EWZmnab+PI499E9cg=;\n\th=Date:From:To:Cc:Subject:References:In-Reply-To:From;\n\tb=WuRSlOg58NJK1N3U//i4+b14ytDZNq1z/Niw99h2BtFpcZTj3/jFeXHlJxxKiPg7u\n\t7LU95cBlJeSK83ATJZ+A3GULiLdMwT7ULjqkwZkeoQ1nBtD2Wo76EBC5SeM+Ra4uE/\n\tCFo0M2YbCYPAODb/R7Zj5KvmiMi/RQ3Gnkpt+2ZU=","Date":"Fri, 28 Aug 2020 17:59:41 +0300","From":"Laurent Pinchart ","To":"Kieran Bingham ","Message-ID":"<20200828145941.GA8557@pendragon.ideasonboard.com>","References":"<20200828115507.305323-1-kieran.bingham@ideasonboard.com>","MIME-Version":"1.0","Content-Disposition":"inline","In-Reply-To":"<20200828115507.305323-1-kieran.bingham@ideasonboard.com>","Subject":"Re: [libcamera-devel] [PATCH] libcamera: buffer: Improve timestamp\n\tdocumentation","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"libcamera devel ","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}},{"id":12224,"web_url":"https://patchwork.libcamera.org/comment/12224/","msgid":"<20200830081124.GR594558@oden.dyn.berto.se>","date":"2020-08-30T08:11:24","subject":"Re: [libcamera-devel] [PATCH] libcamera: buffer: Improve timestamp\n\tdocumentation","submitter":{"id":5,"url":"https://patchwork.libcamera.org/api/people/5/","name":"Niklas Söderlund","email":"niklas.soderlund@ragnatech.se"},"content":"Hello,\n\nOn 2020-08-28 17:59:41 +0300, Laurent Pinchart wrote:\n> Hi Kieran,\n> \n> Thank you for the patch.\n> \n> > The Buffer timestamp documentation is short and does not explain that\n> > the timestamp is based on a monotonic time source, as opposed to the\n> > real/wall-time clocks available in the system.\n> > \n> > Expand upon the statements to detail that it can not be used directly as\n> > a wall-clock for the captured date/time without a further reference\n> > point, and that by taking a reference point - the user will be bringing\n> > in potential inconsistencies which must be considered.\n> > \n> > Signed-off-by: Kieran Bingham \n> > ---\n> > src/libcamera/buffer.cpp | 8 +++++++-\n> > 1 file changed, 7 insertions(+), 1 deletion(-)\n> > \n> > diff --git a/src/libcamera/buffer.cpp b/src/libcamera/buffer.cpp\n> > index a094737d0392..c08ca4234b29 100644\n> > --- a/src/libcamera/buffer.cpp\n> > +++ b/src/libcamera/buffer.cpp\n> > @@ -92,7 +92,13 @@ LOG_DEFINE_CATEGORY(Buffer)\n> > * The timestamp is expressed as a number of nanoseconds relative to the system\n> > * clock since an unspecified time point.\n> > *\n> > - * \\todo Be more precise on what timestamps refer to.\n> > + * This timestamp is monotonic and not affected by changes in system time,\n> > + * however it is still susceptible to small adjustments made by NTP.\n> > + *\n> > + * This clock has no specification on its time base, so can not be directly be\n> > + * converted to a 'real' wall clock time without a comparable reference point.\n> > + * However, continued conversions from the reference point, may bring in\n> > + * inaccuracies due to changes on the real time clock which must be considered.\n> \n> I'd keep a todo here, as we still haven't decided what clock source is\n> the most suitable. Describing what is being done today is of course a\n> good idea, but one issue is that we get the timestamp directly from\n> V4L2, and V4L2 doesn't guarantee what timestamp source is used. I've had\n> a look at Linus' master branch, and we have, in drivers/media/,\n> \n> 103 ktime_get\n> 6 ktime_get_boottime\n> 6 ktime_get_real\n> \n> ktime_get_boottime is only used in DVB, so we're fine there.\n> ktime_get_real is used by\n> \n> drivers/media/pci/ttpci/av7110.c: ktime_get_real_ts64(&ts);\n> drivers/media/rc/streamzap.c: sz->signal_start = ktime_get_real();\n> drivers/media/rc/streamzap.c: sz->signal_start = ktime_get_real();\n> drivers/media/test-drivers/vivid/vivid-rds-gen.c: time64_to_tm(ktime_get_real_seconds(), 0, &tm);\n> drivers/media/test-drivers/vivid/vivid-vbi-gen.c: time64_to_tm(ktime_get_real_seconds(), 0, &tm);\n> drivers/media/usb/uvc/uvc_video.c: return ktime_get_real();\n> \n> UVC supports selecting either the monotonic or real clock, with the\n> monotonic clock being the default, so I think we're fine too.\n> \n> We can thus assume for the time being that we only get CLOCK_MONOTONIC\n> timestamp. Should we simplify the doc by just telling we use\n> CLOCK_MONOTONIC, with a todo comment to revisit the topic and possibly\n> select a different clock, or make the clock source configurable ?\n\nI think we should always use the CLOCK_MONOTONIC for buffer/request \ntimestamps. For other clocks we might have clock drift or adjustment \n(ntp) messing with the values creating subtle bugs. For applications \nwanting to have a stamp to write to file I think they need to create \nthat themself, taking all the localization and timezones into account \n:-)\n\n> \n> > */\n> > \n> > /**\n> \n> -- \n> Regards,\n> \n> Laurent Pinchart\n> _______________________________________________\n> libcamera-devel mailing list\n> libcamera-devel@lists.libcamera.org\n> https://lists.libcamera.org/listinfo/libcamera-devel","headers":{"Return-Path":"","X-Original-To":"parsemail@patchwork.libcamera.org","Delivered-To":"parsemail@patchwork.libcamera.org","Received":["from lancelot.ideasonboard.com (lancelot.ideasonboard.com\n\t[92.243.16.209])\n\tby patchwork.libcamera.org (Postfix) with ESMTPS id 7C533BDC71\n\tfor ;\n\tSun, 30 Aug 2020 08:11:27 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id EB99962912;\n\tSun, 30 Aug 2020 10:11:26 +0200 (CEST)","from mail-lj1-x242.google.com (mail-lj1-x242.google.com\n\t[IPv6:2a00:1450:4864:20::242])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id 2B52461EA0\n\tfor ;\n\tSun, 30 Aug 2020 10:11:26 +0200 (CEST)","by mail-lj1-x242.google.com with SMTP id v12so3293219ljc.10\n\tfor ;\n\tSun, 30 Aug 2020 01:11:26 -0700 (PDT)","from localhost (h-209-203.A463.priv.bahnhof.se. [155.4.209.203])\n\tby smtp.gmail.com with ESMTPSA id\n\ts4sm852391lja.124.2020.08.30.01.11.24\n\t(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);\n\tSun, 30 Aug 2020 01:11:24 -0700 (PDT)"],"Authentication-Results":"lancelot.ideasonboard.com;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=ragnatech-se.20150623.gappssmtp.com\n\theader.i=@ragnatech-se.20150623.gappssmtp.com\n\theader.b=\"StcA1l+x\"; dkim-atps=neutral","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=ragnatech-se.20150623.gappssmtp.com; s=20150623;\n\th=date:from:to:cc:subject:message-id:references:mime-version\n\t:content-disposition:content-transfer-encoding:in-reply-to;\n\tbh=x9lew8hUuEXWbgJeIdI7fgUc83y9g3TtzB7Pdsds9kg=;\n\tb=StcA1l+xFZHNNZrLdVrIB3pTsRInukqV9+wka7MrrrEqWq5xEHnLi0l3/70CBpMnYZ\n\t5Q/EBWCfLY+dUs0rWxGNo4UdrSmltCTVInrwGKFS0ppPMlvY5kgT661Ul5lTu4o2vpMt\n\t5YIrthjqlbSCEq4mDYPIyyC+Q/2Nutl8Vhxi2ooFN1ca5v3UVHgxR/OwpxkSq3czGigF\n\tWzBITQOy2NutQMXyrMt9zCUgeWKtiEpSPtFo6adS6lSrQr/mgOOm2dz1yj1k6VrxH19e\n\tEvShMmjGXKC+GFwdBt65tIU366SyHQB0oZqMsOjqurt7If1KOQnZbNEtBB/iP22e5q3+\n\t4LGQ==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:date:from:to:cc:subject:message-id:references\n\t:mime-version:content-disposition:content-transfer-encoding\n\t:in-reply-to;\n\tbh=x9lew8hUuEXWbgJeIdI7fgUc83y9g3TtzB7Pdsds9kg=;\n\tb=WKzVK1MVXQSczHFT+b8hg8D/yLTaqpVIGutKikCsqcORH1rCrnjFkV5U9Vima5iBjg\n\tHioocmJo4LNLDxlbqeTLjskObi2xd+nia4xtXNtFZIrF/w4uuSTvjliLAQgN23VwQ1Ql\n\tEn2ComwUELb3e/YR7YHk84XkDXFI+eMrWz8E9u59LnvnccPe27VT3lE0J0fuvet1cnde\n\tnBZiXzcOXMasRaE7N+auW+ExedAofWChcqnV65KsL5EZw3L09DQAy1SpRy377QNAkzyJ\n\tR12q/mKcnhMkNUe5jvapJxkLj4p782+C2rHiapK9yI6+WYURC6Da+FMnN6zzaCQbPjz3\n\t1eYg==","X-Gm-Message-State":"AOAM533I9LqmGrmXuog/JmhTa9L7/UCbA/eeLWkwV8eYl2+y/rpjoCK+\n\tBQ6ocWZ+PAqL1mOWfbqzBWhmFg==","X-Google-Smtp-Source":"ABdhPJzu/8N1/5s0jP2hXC1qmDBMC3PV3Y+mp+s3UVl3MoEc8SmFRMpB1igzO5G/ylbrmUcmxezw5g==","X-Received":"by 2002:a05:651c:310:: with SMTP id\n\ta16mr2734892ljp.250.1598775085360; \n\tSun, 30 Aug 2020 01:11:25 -0700 (PDT)","Date":"Sun, 30 Aug 2020 10:11:24 +0200","From":"Niklas =?iso-8859-1?q?S=F6derlund?= ","To":"Laurent Pinchart ","Message-ID":"<20200830081124.GR594558@oden.dyn.berto.se>","References":"<20200828115507.305323-1-kieran.bingham@ideasonboard.com>\n\t<20200828145941.GA8557@pendragon.ideasonboard.com>","MIME-Version":"1.0","Content-Disposition":"inline","In-Reply-To":"<20200828145941.GA8557@pendragon.ideasonboard.com>","Subject":"Re: [libcamera-devel] [PATCH] libcamera: buffer: Improve timestamp\n\tdocumentation","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"libcamera devel ","Content-Type":"text/plain; charset=\"iso-8859-1\"","Content-Transfer-Encoding":"quoted-printable","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}},{"id":12228,"web_url":"https://patchwork.libcamera.org/comment/12228/","msgid":"","date":"2020-08-31T09:41:12","subject":"Re: [libcamera-devel] [PATCH] libcamera: buffer: Improve timestamp\n\tdocumentation","submitter":{"id":4,"url":"https://patchwork.libcamera.org/api/people/4/","name":"Kieran Bingham","email":"kieran.bingham@ideasonboard.com"},"content":"Hi Niklas,\n\nOn 30/08/2020 09:11, Niklas Söderlund wrote:\n> Hello,\n> \n> On 2020-08-28 17:59:41 +0300, Laurent Pinchart wrote:\n>> Hi Kieran,\n>>\n>> Thank you for the patch.\n>>\n>>> The Buffer timestamp documentation is short and does not explain that\n>>> the timestamp is based on a monotonic time source, as opposed to the\n>>> real/wall-time clocks available in the system.\n>>>\n>>> Expand upon the statements to detail that it can not be used directly as\n>>> a wall-clock for the captured date/time without a further reference\n>>> point, and that by taking a reference point - the user will be bringing\n>>> in potential inconsistencies which must be considered.\n>>>\n>>> Signed-off-by: Kieran Bingham \n>>> ---\n>>> src/libcamera/buffer.cpp | 8 +++++++-\n>>> 1 file changed, 7 insertions(+), 1 deletion(-)\n>>>\n>>> diff --git a/src/libcamera/buffer.cpp b/src/libcamera/buffer.cpp\n>>> index a094737d0392..c08ca4234b29 100644\n>>> --- a/src/libcamera/buffer.cpp\n>>> +++ b/src/libcamera/buffer.cpp\n>>> @@ -92,7 +92,13 @@ LOG_DEFINE_CATEGORY(Buffer)\n>>> * The timestamp is expressed as a number of nanoseconds relative to the system\n>>> * clock since an unspecified time point.\n>>> *\n>>> - * \\todo Be more precise on what timestamps refer to.\n>>> + * This timestamp is monotonic and not affected by changes in system time,\n>>> + * however it is still susceptible to small adjustments made by NTP.\n>>> + *\n>>> + * This clock has no specification on its time base, so can not be directly be\n>>> + * converted to a 'real' wall clock time without a comparable reference point.\n>>> + * However, continued conversions from the reference point, may bring in\n>>> + * inaccuracies due to changes on the real time clock which must be considered.\n>>\n>> I'd keep a todo here, as we still haven't decided what clock source is\n>> the most suitable. Describing what is being done today is of course a\n>> good idea, but one issue is that we get the timestamp directly from\n>> V4L2, and V4L2 doesn't guarantee what timestamp source is used. I've had\n>> a look at Linus' master branch, and we have, in drivers/media/,\n>>\n>> 103 ktime_get\n>> 6 ktime_get_boottime\n>> 6 ktime_get_real\n>>\n>> ktime_get_boottime is only used in DVB, so we're fine there.\n>> ktime_get_real is used by\n>>\n>> drivers/media/pci/ttpci/av7110.c: ktime_get_real_ts64(&ts);\n>> drivers/media/rc/streamzap.c: sz->signal_start = ktime_get_real();\n>> drivers/media/rc/streamzap.c: sz->signal_start = ktime_get_real();\n>> drivers/media/test-drivers/vivid/vivid-rds-gen.c: time64_to_tm(ktime_get_real_seconds(), 0, &tm);\n>> drivers/media/test-drivers/vivid/vivid-vbi-gen.c: time64_to_tm(ktime_get_real_seconds(), 0, &tm);\n>> drivers/media/usb/uvc/uvc_video.c: return ktime_get_real();\n>>\n>> UVC supports selecting either the monotonic or real clock, with the\n>> monotonic clock being the default, so I think we're fine too.\n>>\n>> We can thus assume for the time being that we only get CLOCK_MONOTONIC\n>> timestamp. Should we simplify the doc by just telling we use\n>> CLOCK_MONOTONIC, with a todo comment to revisit the topic and possibly\n>> select a different clock, or make the clock source configurable ?\n> \n> I think we should always use the CLOCK_MONOTONIC for buffer/request \n> timestamps. For other clocks we might have clock drift or adjustment \n> (ntp) messing with the values creating subtle bugs. For applications \n> wanting to have a stamp to write to file I think they need to create \n> that themself, taking all the localization and timezones into account \n> :-)\n\nI think perhaps we should be setting the clock explicitly if there are\noptions (which does leave the possibility of it being configurable, but\nonly if all underlying kernel layers support that, not 'just uvc'. ).\n\nI think it's important that all pipeline handlers treat the time stamps\nin the same consistent way though.\n\n\nNiklas, I do mostly agree with you on the fact that the timestamps need\nto be consistent (and monotonic) for performance measurements, but how\nwill we handle the need for encoding the captured time stamp when it\ncomes to the reprocessing API?\n\nWill there be any differences there? Or perhaps it's not a problem, as\nthe layer injecting the frames is also the layer doing the encoding - so\nthe timestamps are just simply a passthrough at that point.\n\n--\nKieran\n\n> \n>>\n>>> */\n>>> \n>>> /**\n>>\n>> -- \n>> Regards,\n>>\n>> Laurent Pinchart\n>> _______________________________________________\n>> libcamera-devel mailing list\n>> libcamera-devel@lists.libcamera.org\n>> https://lists.libcamera.org/listinfo/libcamera-devel\n>","headers":{"Return-Path":"","X-Original-To":"parsemail@patchwork.libcamera.org","Delivered-To":"parsemail@patchwork.libcamera.org","Received":["from lancelot.ideasonboard.com (lancelot.ideasonboard.com\n\t[92.243.16.209])\n\tby patchwork.libcamera.org (Postfix) with ESMTPS id 69B7DBF019\n\tfor ;\n\tMon, 31 Aug 2020 09:41:17 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id D80B662919;\n\tMon, 31 Aug 2020 11:41:16 +0200 (CEST)","from perceval.ideasonboard.com (perceval.ideasonboard.com\n\t[213.167.242.64])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id 6CFDD60376\n\tfor ;\n\tMon, 31 Aug 2020 11:41:15 +0200 (CEST)","from [192.168.0.20]\n\t(cpc89244-aztw30-2-0-cust3082.18-1.cable.virginm.net [86.31.172.11])\n\tby perceval.ideasonboard.com (Postfix) with ESMTPSA id C01F1277;\n\tMon, 31 Aug 2020 11:41:14 +0200 (CEST)"],"Authentication-Results":"lancelot.ideasonboard.com;\n\tdkim=fail reason=\"signature verification failed\" (1024-bit key;\n\tunprotected) header.d=ideasonboard.com header.i=@ideasonboard.com\n\theader.b=\"OfYFtkey\"; dkim-atps=neutral","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com;\n\ts=mail; t=1598866875;\n\tbh=eg0lb2y+TDTz2a+eq9OVU0Xveu8XvkgHMHCCvypGsW0=;\n\th=Reply-To:Subject:To:Cc:References:From:Date:In-Reply-To:From;\n\tb=OfYFtkeySVuwaobwCHrc85LNIMMfLTHSb0U74g1L4yAu3Dpt5NMRfi16ZmVcwgP0P\n\t1glSfhQY2XZuIFA0CcT69NG/JfWean6tUZTvbEGkdoUYwBsrIzga9nonshjsWsHf39\n\thB6YUYskKsMibraxMSNXwGZYbbt+lOugdXIGNiKk=","To":"=?utf-8?q?Niklas_S=C3=B6derlund?= ,\n\tLaurent Pinchart ","References":"<20200828115507.305323-1-kieran.bingham@ideasonboard.com>\n\t<20200828145941.GA8557@pendragon.ideasonboard.com>\n\t<20200830081124.GR594558@oden.dyn.berto.se>","From":"Kieran Bingham ","Autocrypt":"addr=kieran.bingham@ideasonboard.com; keydata=\n\tmQINBFYE/WYBEACs1PwjMD9rgCu1hlIiUA1AXR4rv2v+BCLUq//vrX5S5bjzxKAryRf0uHat\n\tV/zwz6hiDrZuHUACDB7X8OaQcwhLaVlq6byfoBr25+hbZG7G3+5EUl9cQ7dQEdvNj6V6y/SC\n\trRanWfelwQThCHckbobWiQJfK9n7rYNcPMq9B8e9F020LFH7Kj6YmO95ewJGgLm+idg1Kb3C\n\tpotzWkXc1xmPzcQ1fvQMOfMwdS+4SNw4rY9f07Xb2K99rjMwZVDgESKIzhsDB5GY465sCsiQ\n\tcSAZRxqE49RTBq2+EQsbrQpIc8XiffAB8qexh5/QPzCmR4kJgCGeHIXBtgRj+nIkCJPZvZtf\n\tKr2EAbc6tgg6DkAEHJb+1okosV09+0+TXywYvtEop/WUOWQ+zo+Y/OBd+8Ptgt1pDRyOBzL8\n\tRXa8ZqRf0Mwg75D+dKntZeJHzPRJyrlfQokngAAs4PaFt6UfS+ypMAF37T6CeDArQC41V3ko\n\tlPn1yMsVD0p+6i3DPvA/GPIksDC4owjnzVX9kM8Zc5Cx+XoAN0w5Eqo4t6qEVbuettxx55gq\n\t8K8FieAjgjMSxngo/HST8TpFeqI5nVeq0/lqtBRQKumuIqDg+Bkr4L1V/PSB6XgQcOdhtd36\n\tOe9X9dXB8YSNt7VjOcO7BTmFn/Z8r92mSAfHXpb07YJWJosQOQARAQABtDBLaWVyYW4gQmlu\n\tZ2hhbSA8a2llcmFuLmJpbmdoYW1AaWRlYXNvbmJvYXJkLmNvbT6JAlcEEwEKAEECGwMFCwkI\n\tBwIGFQgJCgsCBBYCAwECHgECF4ACGQEWIQSQLdeYP70o/eNy1HqhHkZyEKRh/QUCXWTtygUJ\n\tCyJXZAAKCRChHkZyEKRh/f8dEACTDsbLN2nioNZMwyLuQRUAFcXNolDX48xcUXsWS2QjxaPm\n\tVsJx8Uy8aYkS85mdPBh0C83OovQR/OVbr8AxhGvYqBs3nQvbWuTl/+4od7DfK2VZOoKBAu5S\n\tQK2FYuUcikDqYcFWJ8DQnubxfE8dvzojHEkXw0sA4igINHDDFX3HJGZtLio+WpEFQtCbfTAG\n\tYZslasz1YZRbwEdSsmO3/kqy5eMnczlm8a21A3fKUo3g8oAZEFM+f4DUNzqIltg31OAB/kZS\n\tenKZQ/SWC8PmLg/ZXBrReYakxXtkP6w3FwMlzOlhGxqhIRNiAJfXJBaRhuUWzPOpEDE9q5YJ\n\tBmqQL2WJm1VSNNVxbXJHpaWMH1sA2R00vmvRrPXGwyIO0IPYeUYQa3gsy6k+En/aMQJd27dp\n\taScf9am9PFICPY5T4ppneeJLif2lyLojo0mcHOV+uyrds9XkLpp14GfTkeKPdPMrLLTsHRfH\n\tfA4I4OBpRrEPiGIZB/0im98MkGY/Mu6qxeZmYLCcgD6qz4idOvfgVOrNh+aA8HzIVR+RMW8H\n\tQGBN9f0E3kfwxuhl3omo6V7lDw8XOdmuWZNC9zPq1UfryVHANYbLGz9KJ4Aw6M+OgBC2JpkD\n\thXMdHUkC+d20dwXrwHTlrJi1YNp6rBc+xald3wsUPOZ5z8moTHUX/uPA/qhGsbkCDQRWBP1m\n\tARAAzijkb+Sau4hAncr1JjOY+KyFEdUNxRy+hqTJdJfaYihxyaj0Ee0P0zEi35CbE6lgU0Uz\n\ttih9fiUbSV3wfsWqg1Ut3/5rTKu7kLFp15kF7eqvV4uezXRD3Qu4yjv/rMmEJbbD4cTvGCYI\n\td6MDC417f7vK3hCbCVIZSp3GXxyC1LU+UQr3fFcOyCwmP9vDUR9JV0BSqHHxRDdpUXE26Dk6\n\tmhf0V1YkspE5St814ETXpEus2urZE5yJIUROlWPIL+hm3NEWfAP06vsQUyLvr/GtbOT79vXl\n\tEn1aulcYyu20dRRxhkQ6iILaURcxIAVJJKPi8dsoMnS8pB0QW12AHWuirPF0g6DiuUfPmrA5\n\tPKe56IGlpkjc8cO51lIxHkWTpCMWigRdPDexKX+Sb+W9QWK/0JjIc4t3KBaiG8O4yRX8ml2R\n\t+rxfAVKM6V769P/hWoRGdgUMgYHFpHGSgEt80OKK5HeUPy2cngDUXzwrqiM5Sz6Od0qw5pCk\n\tNlXqI0W/who0iSVM+8+RmyY0OEkxEcci7rRLsGnM15B5PjLJjh1f2ULYkv8s4SnDwMZ/kE04\n\t/UqCMK/KnX8pwXEMCjz0h6qWNpGwJ0/tYIgQJZh6bqkvBrDogAvuhf60Sogw+mH8b+PBlx1L\n\toeTK396wc+4c3BfiC6pNtUS5GpsPMMjYMk7kVvEAEQEAAYkCPAQYAQoAJgIbDBYhBJAt15g/\n\tvSj943LUeqEeRnIQpGH9BQJdizzIBQkLSKZiAAoJEKEeRnIQpGH9eYgQAJpjaWNgqNOnMTmD\n\tMJggbwjIotypzIXfhHNCeTkG7+qCDlSaBPclcPGYrTwCt0YWPU2TgGgJrVhYT20ierN8LUvj\n\t6qOPTd+Uk7NFzL65qkh80ZKNBFddx1AabQpSVQKbdcLb8OFs85kuSvFdgqZwgxA1vl4TFhNz\n\tPZ79NAmXLackAx3sOVFhk4WQaKRshCB7cSl+RIng5S/ThOBlwNlcKG7j7W2MC06BlTbdEkUp\n\tECzuuRBv8wX4OQl+hbWbB/VKIx5HKlLu1eypen/5lNVzSqMMIYkkZcjV2SWQyUGxSwq0O/sx\n\tS0A8/atCHUXOboUsn54qdxrVDaK+6jIAuo8JiRWctP16KjzUM7MO0/+4zllM8EY57rXrj48j\n\tsbEYX0YQnzaj+jO6kJtoZsIaYR7rMMq9aUAjyiaEZpmP1qF/2sYenDx0Fg2BSlLvLvXM0vU8\n\tpQk3kgDu7kb/7PRYrZvBsr21EIQoIjXbZxDz/o7z95frkP71EaICttZ6k9q5oxxA5WC6sTXc\n\tMW8zs8avFNuA9VpXt0YupJd2ijtZy2mpZNG02fFVXhIn4G807G7+9mhuC4XG5rKlBBUXTvPU\n\tAfYnB4JBDLmLzBFavQfvonSfbitgXwCG3vS+9HEwAjU30Bar1PEOmIbiAoMzuKeRm2LVpmq4\n\tWZw01QYHU/GUV/zHJSFk","Organization":"Ideas on Board","Message-ID":"","Date":"Mon, 31 Aug 2020 10:41:12 +0100","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101\n\tThunderbird/68.10.0","MIME-Version":"1.0","In-Reply-To":"<20200830081124.GR594558@oden.dyn.berto.se>","Content-Language":"en-GB","Subject":"Re: [libcamera-devel] [PATCH] libcamera: buffer: Improve timestamp\n\tdocumentation","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Reply-To":"kieran.bingham@ideasonboard.com","Cc":"libcamera devel ","Content-Type":"text/plain; charset=\"utf-8\"","Content-Transfer-Encoding":"base64","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}},{"id":12230,"web_url":"https://patchwork.libcamera.org/comment/12230/","msgid":"<20200831140013.GC16155@pendragon.ideasonboard.com>","date":"2020-08-31T14:00:13","subject":"Re: [libcamera-devel] [PATCH] libcamera: buffer: Improve timestamp\n\tdocumentation","submitter":{"id":2,"url":"https://patchwork.libcamera.org/api/people/2/","name":"Laurent Pinchart","email":"laurent.pinchart@ideasonboard.com"},"content":"On Mon, Aug 31, 2020 at 10:41:12AM +0100, Kieran Bingham wrote:\n> On 30/08/2020 09:11, Niklas Söderlund wrote:\n> > On 2020-08-28 17:59:41 +0300, Laurent Pinchart wrote:\n> >>> The Buffer timestamp documentation is short and does not explain that\n> >>> the timestamp is based on a monotonic time source, as opposed to the\n> >>> real/wall-time clocks available in the system.\n> >>>\n> >>> Expand upon the statements to detail that it can not be used directly as\n> >>> a wall-clock for the captured date/time without a further reference\n> >>> point, and that by taking a reference point - the user will be bringing\n> >>> in potential inconsistencies which must be considered.\n> >>>\n> >>> Signed-off-by: Kieran Bingham \n> >>> ---\n> >>> src/libcamera/buffer.cpp | 8 +++++++-\n> >>> 1 file changed, 7 insertions(+), 1 deletion(-)\n> >>>\n> >>> diff --git a/src/libcamera/buffer.cpp b/src/libcamera/buffer.cpp\n> >>> index a094737d0392..c08ca4234b29 100644\n> >>> --- a/src/libcamera/buffer.cpp\n> >>> +++ b/src/libcamera/buffer.cpp\n> >>> @@ -92,7 +92,13 @@ LOG_DEFINE_CATEGORY(Buffer)\n> >>> * The timestamp is expressed as a number of nanoseconds relative to the system\n> >>> * clock since an unspecified time point.\n> >>> *\n> >>> - * \\todo Be more precise on what timestamps refer to.\n> >>> + * This timestamp is monotonic and not affected by changes in system time,\n> >>> + * however it is still susceptible to small adjustments made by NTP.\n> >>> + *\n> >>> + * This clock has no specification on its time base, so can not be directly be\n> >>> + * converted to a 'real' wall clock time without a comparable reference point.\n> >>> + * However, continued conversions from the reference point, may bring in\n> >>> + * inaccuracies due to changes on the real time clock which must be considered.\n> >>\n> >> I'd keep a todo here, as we still haven't decided what clock source is\n> >> the most suitable. Describing what is being done today is of course a\n> >> good idea, but one issue is that we get the timestamp directly from\n> >> V4L2, and V4L2 doesn't guarantee what timestamp source is used. I've had\n> >> a look at Linus' master branch, and we have, in drivers/media/,\n> >>\n> >> 103 ktime_get\n> >> 6 ktime_get_boottime\n> >> 6 ktime_get_real\n> >>\n> >> ktime_get_boottime is only used in DVB, so we're fine there.\n> >> ktime_get_real is used by\n> >>\n> >> drivers/media/pci/ttpci/av7110.c: ktime_get_real_ts64(&ts);\n> >> drivers/media/rc/streamzap.c: sz->signal_start = ktime_get_real();\n> >> drivers/media/rc/streamzap.c: sz->signal_start = ktime_get_real();\n> >> drivers/media/test-drivers/vivid/vivid-rds-gen.c: time64_to_tm(ktime_get_real_seconds(), 0, &tm);\n> >> drivers/media/test-drivers/vivid/vivid-vbi-gen.c: time64_to_tm(ktime_get_real_seconds(), 0, &tm);\n> >> drivers/media/usb/uvc/uvc_video.c: return ktime_get_real();\n> >>\n> >> UVC supports selecting either the monotonic or real clock, with the\n> >> monotonic clock being the default, so I think we're fine too.\n> >>\n> >> We can thus assume for the time being that we only get CLOCK_MONOTONIC\n> >> timestamp. Should we simplify the doc by just telling we use\n> >> CLOCK_MONOTONIC, with a todo comment to revisit the topic and possibly\n> >> select a different clock, or make the clock source configurable ?\n> > \n> > I think we should always use the CLOCK_MONOTONIC for buffer/request \n> > timestamps. For other clocks we might have clock drift or adjustment \n> > (ntp) messing with the values creating subtle bugs.\n\nCLOCK_MONOTONIC is subject to NTP adjustments. You want\nCLOCK_MONOTONIC_RAW to avoid that.\n\n> > For applications \n> > wanting to have a stamp to write to file I think they need to create \n> > that themself, taking all the localization and timezones into account \n> > :-)\n> \n> I think perhaps we should be setting the clock explicitly if there are\n> options (which does leave the possibility of it being configurable, but\n> only if all underlying kernel layers support that, not 'just uvc'. ).\n> \n> I think it's important that all pipeline handlers treat the time stamps\n> in the same consistent way though.\n\nI believe we'll have to support multiple timestamp sources. Timestamps\nare mostly useful to synchronize events in the system, and to do so,\nclocks need to match. We don't control what clock sources other\nsubsystems use. CLOCK_BOOTTIME is another common alternative to\nCLOCK_MONOTONIC. It will likely be best to just allow the user to select\na timestamp source (we'll need a corresponding kernel API).\n\n> Niklas, I do mostly agree with you on the fact that the timestamps need\n> to be consistent (and monotonic) for performance measurements, but how\n> will we handle the need for encoding the captured time stamp when it\n> comes to the reprocessing API?\n> \n> Will there be any differences there? Or perhaps it's not a problem, as\n> the layer injecting the frames is also the layer doing the encoding - so\n> the timestamps are just simply a passthrough at that point.\n\nYes, timestamps should be passed-through I think.\n\n> >>> */\n> >>> \n> >>> /**","headers":{"Return-Path":"","X-Original-To":"parsemail@patchwork.libcamera.org","Delivered-To":"parsemail@patchwork.libcamera.org","Received":["from lancelot.ideasonboard.com (lancelot.ideasonboard.com\n\t[92.243.16.209])\n\tby patchwork.libcamera.org (Postfix) with ESMTPS id B43BFBF019\n\tfor ;\n\tMon, 31 Aug 2020 14:00:36 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id 2873161ADE;\n\tMon, 31 Aug 2020 16:00:36 +0200 (CEST)","from perceval.ideasonboard.com (perceval.ideasonboard.com\n\t[213.167.242.64])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id 854B061ADE\n\tfor ;\n\tMon, 31 Aug 2020 16:00:34 +0200 (CEST)","from pendragon.ideasonboard.com (62-78-145-57.bb.dnainternet.fi\n\t[62.78.145.57])\n\tby perceval.ideasonboard.com (Postfix) with ESMTPSA id 00743277;\n\tMon, 31 Aug 2020 16:00:33 +0200 (CEST)"],"Authentication-Results":"lancelot.ideasonboard.com;\n\tdkim=fail reason=\"signature verification failed\" (1024-bit key;\n\tunprotected) header.d=ideasonboard.com header.i=@ideasonboard.com\n\theader.b=\"kywb7kiU\"; dkim-atps=neutral","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com;\n\ts=mail; t=1598882434;\n\tbh=IU7xa9RSHOR6cUgWRcb0SNe3QCJpIDAyr+PLj5xxEUc=;\n\th=Date:From:To:Cc:Subject:References:In-Reply-To:From;\n\tb=kywb7kiU9k7inpfvT4u/8giP8nts/KQs5fNee4xS9tsbEs5VB6BAb5gGcBLkNmc1t\n\tKyMYQatDOthumhG7NnzqqM8efk+TjtQ60B4t6u7tV91cT10DW4F/DeWCC95dCvynUg\n\tqjqK6G1gtiEU/H6KMtnAuKiH486+tQlC+0OBe31o=","Date":"Mon, 31 Aug 2020 17:00:13 +0300","From":"Laurent Pinchart ","To":"Kieran Bingham ","Message-ID":"<20200831140013.GC16155@pendragon.ideasonboard.com>","References":"<20200828115507.305323-1-kieran.bingham@ideasonboard.com>\n\t<20200828145941.GA8557@pendragon.ideasonboard.com>\n\t<20200830081124.GR594558@oden.dyn.berto.se>\n\t","MIME-Version":"1.0","Content-Disposition":"inline","In-Reply-To":"","Subject":"Re: [libcamera-devel] [PATCH] libcamera: buffer: Improve timestamp\n\tdocumentation","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"libcamera devel ","Content-Type":"text/plain; charset=\"utf-8\"","Content-Transfer-Encoding":"base64","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}}]