[{"id":31773,"web_url":"https://patchwork.libcamera.org/comment/31773/","msgid":"","date":"2024-10-16T16:10:24","subject":"Re: [PATCH] libcamera: reserve frame sequence reported from the\n\thardware","submitter":{"id":143,"url":"https://patchwork.libcamera.org/api/people/143/","name":"Jacopo Mondi","email":"jacopo.mondi@ideasonboard.com"},"content":"Hi\n\nOn Wed, Oct 16, 2024 at 01:17:28PM +0000, Harvey Yang wrote:\n> From: Yudhistira Erlandinata \n>\n> Originally libcamera resets the sequence to 0 on streamOn. However,\n> However, there are occasions when the user needs the original\n\nHowever, there's one However too much\n\n> hardware sequence to query processing information of the particular\n> frame. The patch reserves the hwSequence in the FrameMetadata.\n>\n> Signed-off-by: Yudhistira Erlandinata \n> Co-developed-by: Harvey Yang \n> Signed-off-by: Harvey Yang \n\nI'm more on the opinion that we should stop zeroing the actual HW\nsequences.\n\nParticularly, as we move towards a model where the camera pipeline\nshould be running even without buffers queued to the video capture\ndevices (iow producing frames from the sensor and stas from the ISP), an\napplication could queue a video buffer later, and we should be able to\ndetect how many frames have been \"missed\" and the existing\n\n if (!firstFrame_.has_value()) {\n\ncheck in V4L2VideoDevice::dequeueBuffer() will produce unwanted\nInfo messages.\n\nKieran in cc as I recall this is something he introduced.\n\nIn the meantime, storing the actual sequence number somewhere I think\nit's fine.\n\n\n> ---\n> include/libcamera/framebuffer.h | 1 +\n> src/libcamera/framebuffer.cpp | 9 +++++++++\n> src/libcamera/v4l2_videodevice.cpp | 1 +\n> 3 files changed, 11 insertions(+)\n>\n> diff --git a/include/libcamera/framebuffer.h b/include/libcamera/framebuffer.h\n> index ff8392430..fccfaa82a 100644\n> --- a/include/libcamera/framebuffer.h\n> +++ b/include/libcamera/framebuffer.h\n> @@ -34,6 +34,7 @@ struct FrameMetadata {\n>\n> \tStatus status;\n> \tunsigned int sequence;\n> +\tunsigned int hwSequence;\n> \tuint64_t timestamp;\n>\n> \tSpan planes() { return planes_; }\n> diff --git a/src/libcamera/framebuffer.cpp b/src/libcamera/framebuffer.cpp\n> index 826848f75..d9d6294bc 100644\n> --- a/src/libcamera/framebuffer.cpp\n> +++ b/src/libcamera/framebuffer.cpp\n> @@ -86,6 +86,15 @@ LOG_DEFINE_CATEGORY(Buffer)\n> * Gaps in the sequence numbers indicate dropped frames.\n> */\n>\n> +/**\n> + * \\var FrameMetadata::hwSequence\n> + * \\brief The real hardware Frame sequence number\n\n * \\brief The hardware frame sequence number as reported by the video device\n> + *\n> + * \\a FrameMetadata::sequence auto-corrects the initial value to zero on frame\n\n * V4L2VideoDevice::dequeueBuffer() auto-corrects\n * FrameMetadata::sequence to zero on stream start. This values\n * stores the non-corrected hardware sequence number as reported by\n * the video device.\n */\n\nReviewed-by: Jacopo Mondi \n\nThanks\n j\n\n> + * start. This value keeps the original hardware sequence to allow users to\n> + * query processing information of particular frames.\n> + */\n> +\n> /**\n> * \\var FrameMetadata::timestamp\n> * \\brief Time when the frame was captured\n> diff --git a/src/libcamera/v4l2_videodevice.cpp b/src/libcamera/v4l2_videodevice.cpp\n> index 14eba0561..9bc677edf 100644\n> --- a/src/libcamera/v4l2_videodevice.cpp\n> +++ b/src/libcamera/v4l2_videodevice.cpp\n> @@ -1862,6 +1862,7 @@ FrameBuffer *V4L2VideoDevice::dequeueBuffer()\n> \t\t\t? FrameMetadata::FrameError\n> \t\t\t: FrameMetadata::FrameSuccess;\n> \tmetadata.sequence = buf.sequence;\n> +\tmetadata.hwSequence = buf.sequence;\n> \tmetadata.timestamp = buf.timestamp.tv_sec * 1000000000ULL\n> \t\t\t + buf.timestamp.tv_usec * 1000ULL;\n>\n> --\n> 2.47.0.rc1.288.g06298d1525-goog\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 43712C326C\n\tfor ;\n\tWed, 16 Oct 2024 16:10:32 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id 396AF6537F;\n\tWed, 16 Oct 2024 18:10:31 +0200 (CEST)","from perceval.ideasonboard.com (perceval.ideasonboard.com\n\t[213.167.242.64])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id AB88D6537E\n\tfor ;\n\tWed, 16 Oct 2024 18:10:29 +0200 (CEST)","from ideasonboard.com (unknown [5.179.178.254])\n\tby perceval.ideasonboard.com (Postfix) with ESMTPSA id 11BB0A2F;\n\tWed, 16 Oct 2024 18:08:45 +0200 (CEST)"],"Authentication-Results":"lancelot.ideasonboard.com; dkim=pass (1024-bit key;\n\tunprotected) header.d=ideasonboard.com header.i=@ideasonboard.com\n\theader.b=\"MAHHFuBA\"; dkim-atps=neutral","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com;\n\ts=mail; t=1729094927;\n\tbh=EidRNE2wwjcaurgS0OInhBNXA6MqLDWtx8c4U3c3NUU=;\n\th=Date:From:To:Cc:Subject:References:In-Reply-To:From;\n\tb=MAHHFuBAcjTgLXcBhzy5lq/ZuG+wM3+RhH3Jqqqxj+5Y0MjUHj1xk63S/xxt6GZm9\n\tpdz8DlooGMBNIUZhoRhgcv7uizViCPZAslhyi7QKHBc3FHgBkpfuHr6x4elZvWF5wx\n\tzI4BhYTgBPEOeNGJSUz+wvdFCg5utfBSipupDq8Y=","Date":"Wed, 16 Oct 2024 18:10:24 +0200","From":"Jacopo Mondi ","To":"Harvey Yang ","Cc":"libcamera-devel@lists.libcamera.org, \n\tYudhistira Erlandinata ,\n\tkieran bingham ","Subject":"Re: [PATCH] libcamera: reserve frame sequence reported from the\n\thardware","Message-ID":"","References":"<20241016131730.3634805-1-chenghaoyang@chromium.org>","MIME-Version":"1.0","Content-Type":"text/plain; charset=utf-8","Content-Disposition":"inline","In-Reply-To":"<20241016131730.3634805-1-chenghaoyang@chromium.org>","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","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}},{"id":31817,"web_url":"https://patchwork.libcamera.org/comment/31817/","msgid":"<172937659347.2485972.8195423053247269678@ping.linuxembedded.co.uk>","date":"2024-10-19T22:23:13","subject":"Re: [PATCH] libcamera: reserve frame sequence reported from the\n\thardware","submitter":{"id":4,"url":"https://patchwork.libcamera.org/api/people/4/","name":"Kieran Bingham","email":"kieran.bingham@ideasonboard.com"},"content":"Quoting Jacopo Mondi (2024-10-16 17:10:24)\n> Hi\n> \n> On Wed, Oct 16, 2024 at 01:17:28PM +0000, Harvey Yang wrote:\n> > From: Yudhistira Erlandinata \n> >\n> > Originally libcamera resets the sequence to 0 on streamOn. However,\n> > However, there are occasions when the user needs the original\n> \n> However, there's one However too much\n> \n> > hardware sequence to query processing information of the particular\n> > frame. The patch reserves the hwSequence in the FrameMetadata.\n> >\n> > Signed-off-by: Yudhistira Erlandinata \n> > Co-developed-by: Harvey Yang \n> > Signed-off-by: Harvey Yang \n> \n> I'm more on the opinion that we should stop zeroing the actual HW\n> sequences.\n> \n> Particularly, as we move towards a model where the camera pipeline\n> should be running even without buffers queued to the video capture\n> devices (iow producing frames from the sensor and stas from the ISP), an\n> application could queue a video buffer later, and we should be able to\n> detect how many frames have been \"missed\" and the existing\n> \n> if (!firstFrame_.has_value()) {\n> \n> check in V4L2VideoDevice::dequeueBuffer() will produce unwanted\n> Info messages.\n> \n> Kieran in cc as I recall this is something he introduced.\n> \n> In the meantime, storing the actual sequence number somewhere I think\n> it's fine.\n\nSo - yes - I think 'knowing' the real hardware sequence number is a good\nthing probably. The original aim of my patch was to make it consistent\nfrom libcamera's perspective that frames start at zero... which I think\nis what drivers are /supposed/ to do.\n\nSo not starting at zero is/was I think a kernel driver bug .. but alas\nthey occur.\n\nAnd yes - the other side of this was to be able to try to align frame\nsequences for pfc ... but if we are going to handle that well then I\nwouldn't object to removing the zeroing or handling it in a different\nfashion - or simply continuing with a zero indexed base for applications\nand tracking \n\n\nI'd be curious to see what the device that needs this is doing at\nstartup ... Do you always get a start at 1 ? or do you get starting\noffsets at 'random' values or something else ?\n\n--\nKieran\n\n> \n> \n> > ---\n> > include/libcamera/framebuffer.h | 1 +\n> > src/libcamera/framebuffer.cpp | 9 +++++++++\n> > src/libcamera/v4l2_videodevice.cpp | 1 +\n> > 3 files changed, 11 insertions(+)\n> >\n> > diff --git a/include/libcamera/framebuffer.h b/include/libcamera/framebuffer.h\n> > index ff8392430..fccfaa82a 100644\n> > --- a/include/libcamera/framebuffer.h\n> > +++ b/include/libcamera/framebuffer.h\n> > @@ -34,6 +34,7 @@ struct FrameMetadata {\n> >\n> > Status status;\n> > unsigned int sequence;\n> > + unsigned int hwSequence;\n> > uint64_t timestamp;\n> >\n> > Span planes() { return planes_; }\n> > diff --git a/src/libcamera/framebuffer.cpp b/src/libcamera/framebuffer.cpp\n> > index 826848f75..d9d6294bc 100644\n> > --- a/src/libcamera/framebuffer.cpp\n> > +++ b/src/libcamera/framebuffer.cpp\n> > @@ -86,6 +86,15 @@ LOG_DEFINE_CATEGORY(Buffer)\n> > * Gaps in the sequence numbers indicate dropped frames.\n> > */\n> >\n> > +/**\n> > + * \\var FrameMetadata::hwSequence\n> > + * \\brief The real hardware Frame sequence number\n> \n> * \\brief The hardware frame sequence number as reported by the video device\n> > + *\n> > + * \\a FrameMetadata::sequence auto-corrects the initial value to zero on frame\n> \n> * V4L2VideoDevice::dequeueBuffer() auto-corrects\n> * FrameMetadata::sequence to zero on stream start. This values\n> * stores the non-corrected hardware sequence number as reported by\n> * the video device.\n> */\n> \n> Reviewed-by: Jacopo Mondi \n> \n> Thanks\n> j\n> \n> > + * start. This value keeps the original hardware sequence to allow users to\n> > + * query processing information of particular frames.\n> > + */\n> > +\n> > /**\n> > * \\var FrameMetadata::timestamp\n> > * \\brief Time when the frame was captured\n> > diff --git a/src/libcamera/v4l2_videodevice.cpp b/src/libcamera/v4l2_videodevice.cpp\n> > index 14eba0561..9bc677edf 100644\n> > --- a/src/libcamera/v4l2_videodevice.cpp\n> > +++ b/src/libcamera/v4l2_videodevice.cpp\n> > @@ -1862,6 +1862,7 @@ FrameBuffer *V4L2VideoDevice::dequeueBuffer()\n> > ? FrameMetadata::FrameError\n> > : FrameMetadata::FrameSuccess;\n> > metadata.sequence = buf.sequence;\n> > + metadata.hwSequence = buf.sequence;\n> > metadata.timestamp = buf.timestamp.tv_sec * 1000000000ULL\n> > + buf.timestamp.tv_usec * 1000ULL;\n> >\n> > --\n> > 2.47.0.rc1.288.g06298d1525-goog\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 A1CC6C3304\n\tfor ;\n\tSat, 19 Oct 2024 22:23:19 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id 292D26538C;\n\tSun, 20 Oct 2024 00:23:18 +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 8A65B633C6\n\tfor ;\n\tSun, 20 Oct 2024 00:23:16 +0200 (CEST)","from pendragon.ideasonboard.com\n\t(cpc89244-aztw30-2-0-cust6594.18-1.cable.virginm.net [86.31.185.195])\n\tby perceval.ideasonboard.com (Postfix) with ESMTPSA id 988C6502;\n\tSun, 20 Oct 2024 00:21:31 +0200 (CEST)"],"Authentication-Results":"lancelot.ideasonboard.com; dkim=pass (1024-bit key;\n\tunprotected) header.d=ideasonboard.com header.i=@ideasonboard.com\n\theader.b=\"WjigvNNN\"; dkim-atps=neutral","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com;\n\ts=mail; t=1729376491;\n\tbh=RTzusjylVF8xyYGBQBoN080wTP3lPGrIPA/XD5P+67o=;\n\th=In-Reply-To:References:Subject:From:Cc:To:Date:From;\n\tb=WjigvNNNTfXXR6T5RAawz++CWmXEsVQTzdvr4X62zzAOuMbAekueEcTfMdd1dXEtq\n\t30NsmAjWBxBhkPoIpohP3vJmGoGoEdtPa1tnOo1NcRh8KM3C7pGACN5ZSj2HQsyCgP\n\tasoPsBM2hp38ggvi6k3Yi9RDBIRecFMfC8IFXxGw=","Content-Type":"text/plain; charset=\"utf-8\"","MIME-Version":"1.0","Content-Transfer-Encoding":"quoted-printable","In-Reply-To":"","References":"<20241016131730.3634805-1-chenghaoyang@chromium.org>\n\t","Subject":"Re: [PATCH] libcamera: reserve frame sequence reported from the\n\thardware","From":"Kieran Bingham ","Cc":"libcamera-devel@lists.libcamera.org,\n\tYudhistira Erlandinata ","To":"Harvey Yang ,\n\tJacopo Mondi ","Date":"Sat, 19 Oct 2024 23:23:13 +0100","Message-ID":"<172937659347.2485972.8195423053247269678@ping.linuxembedded.co.uk>","User-Agent":"alot/0.10","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","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}},{"id":31867,"web_url":"https://patchwork.libcamera.org/comment/31867/","msgid":"","date":"2024-10-21T17:48:46","subject":"Re: [PATCH] libcamera: reserve frame sequence reported from the\n\thardware","submitter":{"id":117,"url":"https://patchwork.libcamera.org/api/people/117/","name":"Cheng-Hao Yang","email":"chenghaoyang@chromium.org"},"content":"Hi Kieran and Jacopo,\n\nOn Sun, Oct 20, 2024 at 6:23 AM Kieran Bingham\n wrote:\n>\n> Quoting Jacopo Mondi (2024-10-16 17:10:24)\n> > Hi\n> >\n> > On Wed, Oct 16, 2024 at 01:17:28PM +0000, Harvey Yang wrote:\n> > > From: Yudhistira Erlandinata \n> > >\n> > > Originally libcamera resets the sequence to 0 on streamOn. However,\n> > > However, there are occasions when the user needs the original\n> >\n> > However, there's one However too much\n\nYes, sorry. I'll remove it in the next version.\nIf we decide to merge this one, please just remove it for me to avoid\nthe spam :)\n\n> >\n> > > hardware sequence to query processing information of the particular\n> > > frame. The patch reserves the hwSequence in the FrameMetadata.\n> > >\n> > > Signed-off-by: Yudhistira Erlandinata \n> > > Co-developed-by: Harvey Yang \n> > > Signed-off-by: Harvey Yang \n> >\n> > I'm more on the opinion that we should stop zeroing the actual HW\n> > sequences.\n> >\n> > Particularly, as we move towards a model where the camera pipeline\n> > should be running even without buffers queued to the video capture\n> > devices (iow producing frames from the sensor and stas from the ISP), an\n> > application could queue a video buffer later, and we should be able to\n> > detect how many frames have been \"missed\" and the existing\n> >\n> > if (!firstFrame_.has_value()) {\n> >\n> > check in V4L2VideoDevice::dequeueBuffer() will produce unwanted\n> > Info messages.\n> >\n> > Kieran in cc as I recall this is something he introduced.\n> >\n> > In the meantime, storing the actual sequence number somewhere I think\n> > it's fine.\n>\n> So - yes - I think 'knowing' the real hardware sequence number is a good\n> thing probably. The original aim of my patch was to make it consistent\n> from libcamera's perspective that frames start at zero... which I think\n> is what drivers are /supposed/ to do.\n>\n> So not starting at zero is/was I think a kernel driver bug .. but alas\n> they occur.\n>\n> And yes - the other side of this was to be able to try to align frame\n> sequences for pfc ... but if we are going to handle that well then I\n> wouldn't object to removing the zeroing or handling it in a different\n> fashion - or simply continuing with a zero indexed base for applications\n> and tracking\n\nI guess you're cut-off'ed again...?\n\n>\n>\n> I'd be curious to see what the device that needs this is doing at\n> startup ... Do you always get a start at 1 ? or do you get starting\n> offsets at 'random' values or something else ?\n\nI got some `1`s and `5`s. Seems quite consistent though, FYI.\n\nBR,\nHarvey\n\n>\n> --\n> Kieran\n>\n> >\n> >\n> > > ---\n> > > include/libcamera/framebuffer.h | 1 +\n> > > src/libcamera/framebuffer.cpp | 9 +++++++++\n> > > src/libcamera/v4l2_videodevice.cpp | 1 +\n> > > 3 files changed, 11 insertions(+)\n> > >\n> > > diff --git a/include/libcamera/framebuffer.h b/include/libcamera/framebuffer.h\n> > > index ff8392430..fccfaa82a 100644\n> > > --- a/include/libcamera/framebuffer.h\n> > > +++ b/include/libcamera/framebuffer.h\n> > > @@ -34,6 +34,7 @@ struct FrameMetadata {\n> > >\n> > > Status status;\n> > > unsigned int sequence;\n> > > + unsigned int hwSequence;\n> > > uint64_t timestamp;\n> > >\n> > > Span planes() { return planes_; }\n> > > diff --git a/src/libcamera/framebuffer.cpp b/src/libcamera/framebuffer.cpp\n> > > index 826848f75..d9d6294bc 100644\n> > > --- a/src/libcamera/framebuffer.cpp\n> > > +++ b/src/libcamera/framebuffer.cpp\n> > > @@ -86,6 +86,15 @@ LOG_DEFINE_CATEGORY(Buffer)\n> > > * Gaps in the sequence numbers indicate dropped frames.\n> > > */\n> > >\n> > > +/**\n> > > + * \\var FrameMetadata::hwSequence\n> > > + * \\brief The real hardware Frame sequence number\n> >\n> > * \\brief The hardware frame sequence number as reported by the video device\n> > > + *\n> > > + * \\a FrameMetadata::sequence auto-corrects the initial value to zero on frame\n> >\n> > * V4L2VideoDevice::dequeueBuffer() auto-corrects\n> > * FrameMetadata::sequence to zero on stream start. This values\n> > * stores the non-corrected hardware sequence number as reported by\n> > * the video device.\n> > */\n> >\n> > Reviewed-by: Jacopo Mondi \n> >\n> > Thanks\n> > j\n> >\n> > > + * start. This value keeps the original hardware sequence to allow users to\n> > > + * query processing information of particular frames.\n> > > + */\n> > > +\n> > > /**\n> > > * \\var FrameMetadata::timestamp\n> > > * \\brief Time when the frame was captured\n> > > diff --git a/src/libcamera/v4l2_videodevice.cpp b/src/libcamera/v4l2_videodevice.cpp\n> > > index 14eba0561..9bc677edf 100644\n> > > --- a/src/libcamera/v4l2_videodevice.cpp\n> > > +++ b/src/libcamera/v4l2_videodevice.cpp\n> > > @@ -1862,6 +1862,7 @@ FrameBuffer *V4L2VideoDevice::dequeueBuffer()\n> > > ? FrameMetadata::FrameError\n> > > : FrameMetadata::FrameSuccess;\n> > > metadata.sequence = buf.sequence;\n> > > + metadata.hwSequence = buf.sequence;\n> > > metadata.timestamp = buf.timestamp.tv_sec * 1000000000ULL\n> > > + buf.timestamp.tv_usec * 1000ULL;\n> > >\n> > > --\n> > > 2.47.0.rc1.288.g06298d1525-goog\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 D29DBC32A3\n\tfor ;\n\tMon, 21 Oct 2024 17:49:02 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id 7DD9B65392;\n\tMon, 21 Oct 2024 19:49:01 +0200 (CEST)","from mail-lj1-x234.google.com (mail-lj1-x234.google.com\n\t[IPv6:2a00:1450:4864:20::234])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id ED3DC6538A\n\tfor ;\n\tMon, 21 Oct 2024 19:48:58 +0200 (CEST)","by mail-lj1-x234.google.com with SMTP id\n\t38308e7fff4ca-2fb3ce15172so53056411fa.0\n\tfor ;\n\tMon, 21 Oct 2024 10:48:58 -0700 (PDT)"],"Authentication-Results":"lancelot.ideasonboard.com; dkim=pass (1024-bit key;\n\tunprotected) header.d=chromium.org header.i=@chromium.org\n\theader.b=\"N0GYw9x5\"; dkim-atps=neutral","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=chromium.org; s=google; t=1729532938; x=1730137738;\n\tdarn=lists.libcamera.org; \n\th=content-transfer-encoding:cc:to:subject:message-id:date:from\n\t:in-reply-to:references:mime-version:from:to:cc:subject:date\n\t:message-id:reply-to;\n\tbh=TeQZG2Ezc7VVe3CyrD+JDH8HnQH+ZTd+GmbkfAKN8F4=;\n\tb=N0GYw9x5+lVUqpO2VcvsNJNWo3mQgajZpkpt2W/TOdtv7hUZrDLQqe2k17zB1RTPc5\n\tYDgHJf/uDMWZ03CLnxn9E6cwjl+sBxNfbE7W6fVfhLwSlt88XZeZJZXmIrH+Wzk11zTp\n\trxuCEqysbECvU/dNPuvgkD1JFGDnEiCSVlj0U=","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20230601; t=1729532938; x=1730137738;\n\th=content-transfer-encoding:cc:to:subject:message-id:date:from\n\t:in-reply-to:references:mime-version:x-gm-message-state:from:to:cc\n\t:subject:date:message-id:reply-to;\n\tbh=TeQZG2Ezc7VVe3CyrD+JDH8HnQH+ZTd+GmbkfAKN8F4=;\n\tb=PtayQGeIJrkMONtJCTKgc9TLRuBKxm8Hq1/IBeFy0RjiXcJs+xhZNwGTtswKZmw37l\n\tcqONme9lAKH5RUEpPWgl4ZkJdxuo5YrCACzrhDAMVYV4LTTLwTrSWygBWPqzWeFzfK0X\n\tFtMDYxtbtnDkQV7QC/qD9ej08/9yk3k6G/O76POMpYfss+7k0gZjdKv6rcfRiS0RZJNH\n\tMwK9uLUEINnDDaD663cv07oOJfMx60oH1dZP7UWkz/TyPh1CaYXaXZyNAjAe6Mm2IyWM\n\tBWlKZ3QsifhiPJVli2OiN747rE7ENxylF+C6TfF01Uuv0wsiyUY+DN+LXHqA/uIlepD5\n\taT/A==","X-Forwarded-Encrypted":"i=1;\n\tAJvYcCXWd7IeOmsL8ox8MaLWEj/VaEh0gIlzGqjoTpLCfP6TqQ8r+vDyPGrynUCbaMRqtqJCLALFZhHyClwaKLcod8M=@lists.libcamera.org","X-Gm-Message-State":"AOJu0YxV5gZWa79d7AeAmGgILeV2VFUngS0ZAdQPEukVAC8dUuiv2KSi\n\tLzdzKscdIW8Qhgs0NTLBDxa6gC5mM7vHRDJiJDkapfRAnhWmlx1UBrv8SGlAz4bKtUkllvH2ash\n\trFzgttUBbxERsdk0H4WekZns06g6yxUeVjGAEP5i8kxTnuH8=","X-Google-Smtp-Source":"AGHT+IHThQzOB4UdqIDHhONTy5dLZ5n98ANaU02DAzPlehq/6B6zFCcPEjRDpS2pwzeWe5CZDbY+WsaHQF19WfXnF0I=","X-Received":"by 2002:a2e:bc21:0:b0:2f7:6277:f2be with SMTP id\n\t38308e7fff4ca-2fc91d4b18cmr1338961fa.22.1729532937815;\n\tMon, 21 Oct 2024 10:48:57 -0700 (PDT)","MIME-Version":"1.0","References":"<20241016131730.3634805-1-chenghaoyang@chromium.org>\n\t\n\t<172937659347.2485972.8195423053247269678@ping.linuxembedded.co.uk>","In-Reply-To":"<172937659347.2485972.8195423053247269678@ping.linuxembedded.co.uk>","From":"Cheng-Hao Yang ","Date":"Tue, 22 Oct 2024 01:48:46 +0800","Message-ID":"","Subject":"Re: [PATCH] libcamera: reserve frame sequence reported from the\n\thardware","To":"Kieran Bingham ","Cc":"Jacopo Mondi ,\n\tlibcamera-devel@lists.libcamera.org, \n\tYudhistira Erlandinata ","Content-Type":"text/plain; charset=\"UTF-8\"","Content-Transfer-Encoding":"quoted-printable","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","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}},{"id":32445,"web_url":"https://patchwork.libcamera.org/comment/32445/","msgid":"<173281690535.1605529.2472067796791566202@ping.linuxembedded.co.uk>","date":"2024-11-28T18:01:45","subject":"Re: [PATCH] libcamera: reserve frame sequence reported from the\n\thardware","submitter":{"id":4,"url":"https://patchwork.libcamera.org/api/people/4/","name":"Kieran Bingham","email":"kieran.bingham@ideasonboard.com"},"content":"Quoting Cheng-Hao Yang (2024-10-21 18:48:46)\n> Hi Kieran and Jacopo,\n> \n> On Sun, Oct 20, 2024 at 6:23 AM Kieran Bingham\n> wrote:\n> >\n> > Quoting Jacopo Mondi (2024-10-16 17:10:24)\n> > > Hi\n> > >\n> > > On Wed, Oct 16, 2024 at 01:17:28PM +0000, Harvey Yang wrote:\n> > > > From: Yudhistira Erlandinata \n> > > >\n> > > > Originally libcamera resets the sequence to 0 on streamOn. However,\n> > > > However, there are occasions when the user needs the original\n> > >\n> > > However, there's one However too much\n> \n> Yes, sorry. I'll remove it in the next version.\n> If we decide to merge this one, please just remove it for me to avoid\n> the spam :)\n> \n> > >\n> > > > hardware sequence to query processing information of the particular\n> > > > frame. The patch reserves the hwSequence in the FrameMetadata.\n> > > >\n> > > > Signed-off-by: Yudhistira Erlandinata \n> > > > Co-developed-by: Harvey Yang \n> > > > Signed-off-by: Harvey Yang \n> > >\n> > > I'm more on the opinion that we should stop zeroing the actual HW\n> > > sequences.\n> > >\n> > > Particularly, as we move towards a model where the camera pipeline\n> > > should be running even without buffers queued to the video capture\n> > > devices (iow producing frames from the sensor and stas from the ISP), an\n> > > application could queue a video buffer later, and we should be able to\n> > > detect how many frames have been \"missed\" and the existing\n> > >\n> > > if (!firstFrame_.has_value()) {\n> > >\n> > > check in V4L2VideoDevice::dequeueBuffer() will produce unwanted\n> > > Info messages.\n> > >\n> > > Kieran in cc as I recall this is something he introduced.\n> > >\n> > > In the meantime, storing the actual sequence number somewhere I think\n> > > it's fine.\n> >\n> > So - yes - I think 'knowing' the real hardware sequence number is a good\n> > thing probably. The original aim of my patch was to make it consistent\n> > from libcamera's perspective that frames start at zero... which I think\n> > is what drivers are /supposed/ to do.\n> >\n> > So not starting at zero is/was I think a kernel driver bug .. but alas\n> > they occur.\n> >\n> > And yes - the other side of this was to be able to try to align frame\n> > sequences for pfc ... but if we are going to handle that well then I\n> > wouldn't object to removing the zeroing or handling it in a different\n> > fashion - or simply continuing with a zero indexed base for applications\n> > and tracking\n> \n> I guess you're cut-off'ed again...?\n\nAside from missing a full stop at the end I don't think so?\n\nI was saying I don't mind tracking this or removing the code I added\nearlier\n\n> \n> >\n> >\n> > I'd be curious to see what the device that needs this is doing at\n> > startup ... Do you always get a start at 1 ? or do you get starting\n> > offsets at 'random' values or something else ?\n> \n> I got some `1`s and `5`s. Seems quite consistent though, FYI.\n> \n> BR,\n> Harvey\n> \n> >\n> > --\n> > Kieran\n> >\n> > >\n> > >\n> > > > ---\n> > > > include/libcamera/framebuffer.h | 1 +\n> > > > src/libcamera/framebuffer.cpp | 9 +++++++++\n> > > > src/libcamera/v4l2_videodevice.cpp | 1 +\n> > > > 3 files changed, 11 insertions(+)\n> > > >\n> > > > diff --git a/include/libcamera/framebuffer.h b/include/libcamera/framebuffer.h\n> > > > index ff8392430..fccfaa82a 100644\n> > > > --- a/include/libcamera/framebuffer.h\n> > > > +++ b/include/libcamera/framebuffer.h\n> > > > @@ -34,6 +34,7 @@ struct FrameMetadata {\n> > > >\n> > > > Status status;\n> > > > unsigned int sequence;\n> > > > + unsigned int hwSequence;\n> > > > uint64_t timestamp;\n> > > >\n> > > > Span planes() { return planes_; }\n> > > > diff --git a/src/libcamera/framebuffer.cpp b/src/libcamera/framebuffer.cpp\n> > > > index 826848f75..d9d6294bc 100644\n> > > > --- a/src/libcamera/framebuffer.cpp\n> > > > +++ b/src/libcamera/framebuffer.cpp\n> > > > @@ -86,6 +86,15 @@ LOG_DEFINE_CATEGORY(Buffer)\n> > > > * Gaps in the sequence numbers indicate dropped frames.\n> > > > */\n> > > >\n> > > > +/**\n> > > > + * \\var FrameMetadata::hwSequence\n> > > > + * \\brief The real hardware Frame sequence number\n> > >\n> > > * \\brief The hardware frame sequence number as reported by the video device\n> > > > + *\n> > > > + * \\a FrameMetadata::sequence auto-corrects the initial value to zero on frame\n> > >\n> > > * V4L2VideoDevice::dequeueBuffer() auto-corrects\n> > > * FrameMetadata::sequence to zero on stream start. This values\n> > > * stores the non-corrected hardware sequence number as reported by\n> > > * the video device.\n> > > */\n> > >\n> > > Reviewed-by: Jacopo Mondi \n\nCan you do an update with Jacopo's suggestions please?\n\n--\nKieran\n\n\n> > >\n> > > Thanks\n> > > j\n> > >\n> > > > + * start. This value keeps the original hardware sequence to allow users to\n> > > > + * query processing information of particular frames.\n> > > > + */\n> > > > +\n> > > > /**\n> > > > * \\var FrameMetadata::timestamp\n> > > > * \\brief Time when the frame was captured\n> > > > diff --git a/src/libcamera/v4l2_videodevice.cpp b/src/libcamera/v4l2_videodevice.cpp\n> > > > index 14eba0561..9bc677edf 100644\n> > > > --- a/src/libcamera/v4l2_videodevice.cpp\n> > > > +++ b/src/libcamera/v4l2_videodevice.cpp\n> > > > @@ -1862,6 +1862,7 @@ FrameBuffer *V4L2VideoDevice::dequeueBuffer()\n> > > > ? FrameMetadata::FrameError\n> > > > : FrameMetadata::FrameSuccess;\n> > > > metadata.sequence = buf.sequence;\n> > > > + metadata.hwSequence = buf.sequence;\n> > > > metadata.timestamp = buf.timestamp.tv_sec * 1000000000ULL\n> > > > + buf.timestamp.tv_usec * 1000ULL;\n> > > >\n> > > > --\n> > > > 2.47.0.rc1.288.g06298d1525-goog\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 4606EBD78E\n\tfor ;\n\tThu, 28 Nov 2024 18:01:50 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id 8B01265FCE;\n\tThu, 28 Nov 2024 19:01:49 +0100 (CET)","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 0777A65898\n\tfor ;\n\tThu, 28 Nov 2024 19:01:48 +0100 (CET)","from pendragon.ideasonboard.com\n\t(cpc89244-aztw30-2-0-cust6594.18-1.cable.virginm.net [86.31.185.195])\n\tby perceval.ideasonboard.com (Postfix) with ESMTPSA id EE8B059D;\n\tThu, 28 Nov 2024 19:01:23 +0100 (CET)"],"Authentication-Results":"lancelot.ideasonboard.com; dkim=pass (1024-bit key;\n\tunprotected) header.d=ideasonboard.com header.i=@ideasonboard.com\n\theader.b=\"cPC24JY2\"; dkim-atps=neutral","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com;\n\ts=mail; t=1732816884;\n\tbh=B8KPr2ZGnzVw5D2dyWEFQXFN7VgprnLkSMoPEkXUYso=;\n\th=In-Reply-To:References:Subject:From:Cc:To:Date:From;\n\tb=cPC24JY2pkfY8UDB+8LUqTPijIWubif+h7ykG1bXoM/cQJEJlKJBpuAAV2w7jRfpc\n\tHv9G9gH+eEUMmJcli3VgbmH2Xt5KsKML+/Zp8faK3Gwm8/9KjK91dAb5klMCNbe+bs\n\t7ZDbJQjv28CEg2uBso9OjHgQO9BuoW70tkIHntrQ=","Content-Type":"text/plain; charset=\"utf-8\"","MIME-Version":"1.0","Content-Transfer-Encoding":"quoted-printable","In-Reply-To":"","References":"<20241016131730.3634805-1-chenghaoyang@chromium.org>\n\t\n\t<172937659347.2485972.8195423053247269678@ping.linuxembedded.co.uk>\n\t","Subject":"Re: [PATCH] libcamera: reserve frame sequence reported from the\n\thardware","From":"Kieran Bingham ","Cc":"Jacopo Mondi ,\n\tlibcamera-devel@lists.libcamera.org,\n\tYudhistira Erlandinata ","To":"Cheng-Hao Yang ","Date":"Thu, 28 Nov 2024 18:01:45 +0000","Message-ID":"<173281690535.1605529.2472067796791566202@ping.linuxembedded.co.uk>","User-Agent":"alot/0.10","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","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}},{"id":32447,"web_url":"https://patchwork.libcamera.org/comment/32447/","msgid":"<20241128200144.GD25839@pendragon.ideasonboard.com>","date":"2024-11-28T20:01:44","subject":"Re: [PATCH] libcamera: reserve frame sequence reported from the\n\thardware","submitter":{"id":2,"url":"https://patchwork.libcamera.org/api/people/2/","name":"Laurent Pinchart","email":"laurent.pinchart@ideasonboard.com"},"content":"On Tue, Oct 22, 2024 at 01:48:46AM +0800, Cheng-Hao Yang wrote:\n> On Sun, Oct 20, 2024 at 6:23 AM Kieran Bingham wrote:\n> > Quoting Jacopo Mondi (2024-10-16 17:10:24)\n> > > On Wed, Oct 16, 2024 at 01:17:28PM +0000, Harvey Yang wrote:\n> > > > From: Yudhistira Erlandinata \n> > > >\n> > > > Originally libcamera resets the sequence to 0 on streamOn. However,\n> > > > However, there are occasions when the user needs the original\n> > >\n> > > However, there's one However too much\n> \n> Yes, sorry. I'll remove it in the next version.\n> If we decide to merge this one, please just remove it for me to avoid\n> the spam :)\n> \n> > > > hardware sequence to query processing information of the particular\n> > > > frame. The patch reserves the hwSequence in the FrameMetadata.\n\nWhat are the use cases for this ? The sequence number provided by V4L2\nis supposed to be internal only, why does it need to be exposed to\napplications ? Or is this meant for internal use only ? If so it\nshouldn't be exposed in the public API.\n\n> > > >\n> > > > Signed-off-by: Yudhistira Erlandinata \n> > > > Co-developed-by: Harvey Yang \n> > > > Signed-off-by: Harvey Yang \n> > >\n> > > I'm more on the opinion that we should stop zeroing the actual HW\n> > > sequences.\n> > >\n> > > Particularly, as we move towards a model where the camera pipeline\n> > > should be running even without buffers queued to the video capture\n> > > devices (iow producing frames from the sensor and stas from the ISP), an\n> > > application could queue a video buffer later, and we should be able to\n> > > detect how many frames have been \"missed\" and the existing\n> > >\n> > > if (!firstFrame_.has_value()) {\n> > >\n> > > check in V4L2VideoDevice::dequeueBuffer() will produce unwanted\n> > > Info messages.\n> > >\n> > > Kieran in cc as I recall this is something he introduced.\n> > >\n> > > In the meantime, storing the actual sequence number somewhere I think\n> > > it's fine.\n> >\n> > So - yes - I think 'knowing' the real hardware sequence number is a good\n> > thing probably. The original aim of my patch was to make it consistent\n> > from libcamera's perspective that frames start at zero... which I think\n> > is what drivers are /supposed/ to do.\n> >\n> > So not starting at zero is/was I think a kernel driver bug .. but alas\n> > they occur.\n> >\n> > And yes - the other side of this was to be able to try to align frame\n> > sequences for pfc ... but if we are going to handle that well then I\n> > wouldn't object to removing the zeroing or handling it in a different\n> > fashion - or simply continuing with a zero indexed base for applications\n> > and tracking\n> \n> I guess you're cut-off'ed again...?\n> \n> > I'd be curious to see what the device that needs this is doing at\n> > startup ... Do you always get a start at 1 ? or do you get starting\n> > offsets at 'random' values or something else ?\n> \n> I got some `1`s and `5`s. Seems quite consistent though, FYI.\n\nWhat device is that ?\n\n> > > > ---\n> > > > include/libcamera/framebuffer.h | 1 +\n> > > > src/libcamera/framebuffer.cpp | 9 +++++++++\n> > > > src/libcamera/v4l2_videodevice.cpp | 1 +\n> > > > 3 files changed, 11 insertions(+)\n> > > >\n> > > > diff --git a/include/libcamera/framebuffer.h b/include/libcamera/framebuffer.h\n> > > > index ff8392430..fccfaa82a 100644\n> > > > --- a/include/libcamera/framebuffer.h\n> > > > +++ b/include/libcamera/framebuffer.h\n> > > > @@ -34,6 +34,7 @@ struct FrameMetadata {\n> > > >\n> > > > Status status;\n> > > > unsigned int sequence;\n> > > > + unsigned int hwSequence;\n> > > > uint64_t timestamp;\n> > > >\n> > > > Span planes() { return planes_; }\n> > > > diff --git a/src/libcamera/framebuffer.cpp b/src/libcamera/framebuffer.cpp\n> > > > index 826848f75..d9d6294bc 100644\n> > > > --- a/src/libcamera/framebuffer.cpp\n> > > > +++ b/src/libcamera/framebuffer.cpp\n> > > > @@ -86,6 +86,15 @@ LOG_DEFINE_CATEGORY(Buffer)\n> > > > * Gaps in the sequence numbers indicate dropped frames.\n> > > > */\n> > > >\n> > > > +/**\n> > > > + * \\var FrameMetadata::hwSequence\n> > > > + * \\brief The real hardware Frame sequence number\n> > >\n> > > * \\brief The hardware frame sequence number as reported by the video device\n> > > > + *\n> > > > + * \\a FrameMetadata::sequence auto-corrects the initial value to zero on frame\n> > >\n> > > * V4L2VideoDevice::dequeueBuffer() auto-corrects\n> > > * FrameMetadata::sequence to zero on stream start. This values\n> > > * stores the non-corrected hardware sequence number as reported by\n> > > * the video device.\n> > > */\n> > >\n> > > Reviewed-by: Jacopo Mondi \n> > >\n> > > Thanks\n> > > j\n> > >\n> > > > + * start. This value keeps the original hardware sequence to allow users to\n> > > > + * query processing information of particular frames.\n> > > > + */\n> > > > +\n> > > > /**\n> > > > * \\var FrameMetadata::timestamp\n> > > > * \\brief Time when the frame was captured\n> > > > diff --git a/src/libcamera/v4l2_videodevice.cpp b/src/libcamera/v4l2_videodevice.cpp\n> > > > index 14eba0561..9bc677edf 100644\n> > > > --- a/src/libcamera/v4l2_videodevice.cpp\n> > > > +++ b/src/libcamera/v4l2_videodevice.cpp\n> > > > @@ -1862,6 +1862,7 @@ FrameBuffer *V4L2VideoDevice::dequeueBuffer()\n> > > > ? FrameMetadata::FrameError\n> > > > : FrameMetadata::FrameSuccess;\n> > > > metadata.sequence = buf.sequence;\n> > > > + metadata.hwSequence = buf.sequence;\n> > > > metadata.timestamp = buf.timestamp.tv_sec * 1000000000ULL\n> > > > + buf.timestamp.tv_usec * 1000ULL;\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 4E832C3220\n\tfor ;\n\tThu, 28 Nov 2024 20:01:58 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id 7123265FC0;\n\tThu, 28 Nov 2024 21:01:57 +0100 (CET)","from perceval.ideasonboard.com (perceval.ideasonboard.com\n\t[213.167.242.64])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id 4279C65FC0\n\tfor ;\n\tThu, 28 Nov 2024 21:01:55 +0100 (CET)","from pendragon.ideasonboard.com (81-175-209-231.bb.dnainternet.fi\n\t[81.175.209.231])\n\tby perceval.ideasonboard.com (Postfix) with ESMTPSA id D8BC159D;\n\tThu, 28 Nov 2024 21:01:30 +0100 (CET)"],"Authentication-Results":"lancelot.ideasonboard.com; dkim=pass (1024-bit key;\n\tunprotected) header.d=ideasonboard.com header.i=@ideasonboard.com\n\theader.b=\"BOi4kKcQ\"; dkim-atps=neutral","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com;\n\ts=mail; t=1732824091;\n\tbh=+EPbHdwQ/ldAcz645kz6KECWfkPokk8s4AssYvLGqOs=;\n\th=Date:From:To:Cc:Subject:References:In-Reply-To:From;\n\tb=BOi4kKcQL/VnNJ1t7bimKMz6Tp7UfasOuQWeaDpESDuM0HxAguT5qBlKrQ9MLA1Xo\n\tO4o8A50KAgyyJ+iintHrK6+rKeh/4nc10s6CKEa362BJF2bUDot59TlJcj5ZtNqkBK\n\tPCAJAs5jgGJVdQW8Luct0HnzasfiKVSu8+CAmSpg=","Date":"Thu, 28 Nov 2024 22:01:44 +0200","From":"Laurent Pinchart ","To":"Cheng-Hao Yang ","Cc":"Kieran Bingham ,\n\tJacopo Mondi ,\n\tlibcamera-devel@lists.libcamera.org,\n\tYudhistira Erlandinata ","Subject":"Re: [PATCH] libcamera: reserve frame sequence reported from the\n\thardware","Message-ID":"<20241128200144.GD25839@pendragon.ideasonboard.com>","References":"<20241016131730.3634805-1-chenghaoyang@chromium.org>\n\t\n\t<172937659347.2485972.8195423053247269678@ping.linuxembedded.co.uk>\n\t","MIME-Version":"1.0","Content-Type":"text/plain; charset=utf-8","Content-Disposition":"inline","Content-Transfer-Encoding":"8bit","In-Reply-To":"","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","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}},{"id":32450,"web_url":"https://patchwork.libcamera.org/comment/32450/","msgid":"","date":"2024-11-29T07:53:36","subject":"Re: [PATCH] libcamera: reserve frame sequence reported from the\n\thardware","submitter":{"id":143,"url":"https://patchwork.libcamera.org/api/people/143/","name":"Jacopo Mondi","email":"jacopo.mondi@ideasonboard.com"},"content":"Hi Laurent\n\nOn Thu, Nov 28, 2024 at 10:01:44PM +0200, Laurent Pinchart wrote:\n> On Tue, Oct 22, 2024 at 01:48:46AM +0800, Cheng-Hao Yang wrote:\n> > On Sun, Oct 20, 2024 at 6:23 AM Kieran Bingham wrote:\n> > > Quoting Jacopo Mondi (2024-10-16 17:10:24)\n> > > > On Wed, Oct 16, 2024 at 01:17:28PM +0000, Harvey Yang wrote:\n> > > > > From: Yudhistira Erlandinata \n> > > > >\n> > > > > Originally libcamera resets the sequence to 0 on streamOn. However,\n> > > > > However, there are occasions when the user needs the original\n> > > >\n> > > > However, there's one However too much\n> >\n> > Yes, sorry. I'll remove it in the next version.\n> > If we decide to merge this one, please just remove it for me to avoid\n> > the spam :)\n> >\n> > > > > hardware sequence to query processing information of the particular\n> > > > > frame. The patch reserves the hwSequence in the FrameMetadata.\n>\n> What are the use cases for this ? The sequence number provided by V4L2\n> is supposed to be internal only, why does it need to be exposed to\n> applications ? Or is this meant for internal use only ? If so it\n> shouldn't be exposed in the public API.\n>\n\nWe currently zero the sequence number\nhttps://git.libcamera.org/libcamera/libcamera.git/tree/src/libcamera/v4l2_videodevice.cpp#n1871\n\nPlease note getting somewhere back the 'real' frame number is relevant\nfor PFC as well.\n\n> > > > >\n> > > > > Signed-off-by: Yudhistira Erlandinata \n> > > > > Co-developed-by: Harvey Yang \n> > > > > Signed-off-by: Harvey Yang \n> > > >\n> > > > I'm more on the opinion that we should stop zeroing the actual HW\n> > > > sequences.\n> > > >\n> > > > Particularly, as we move towards a model where the camera pipeline\n> > > > should be running even without buffers queued to the video capture\n> > > > devices (iow producing frames from the sensor and stas from the ISP), an\n> > > > application could queue a video buffer later, and we should be able to\n> > > > detect how many frames have been \"missed\" and the existing\n> > > >\n> > > > if (!firstFrame_.has_value()) {\n> > > >\n> > > > check in V4L2VideoDevice::dequeueBuffer() will produce unwanted\n> > > > Info messages.\n> > > >\n> > > > Kieran in cc as I recall this is something he introduced.\n> > > >\n> > > > In the meantime, storing the actual sequence number somewhere I think\n> > > > it's fine.\n> > >\n> > > So - yes - I think 'knowing' the real hardware sequence number is a good\n> > > thing probably. The original aim of my patch was to make it consistent\n> > > from libcamera's perspective that frames start at zero... which I think\n> > > is what drivers are /supposed/ to do.\n> > >\n> > > So not starting at zero is/was I think a kernel driver bug .. but alas\n> > > they occur.\n> > >\n> > > And yes - the other side of this was to be able to try to align frame\n> > > sequences for pfc ... but if we are going to handle that well then I\n> > > wouldn't object to removing the zeroing or handling it in a different\n> > > fashion - or simply continuing with a zero indexed base for applications\n> > > and tracking\n> >\n> > I guess you're cut-off'ed again...?\n> >\n> > > I'd be curious to see what the device that needs this is doing at\n> > > startup ... Do you always get a start at 1 ? or do you get starting\n> > > offsets at 'random' values or something else ?\n> >\n> > I got some `1`s and `5`s. Seems quite consistent though, FYI.\n>\n> What device is that ?\n>\n> > > > > ---\n> > > > > include/libcamera/framebuffer.h | 1 +\n> > > > > src/libcamera/framebuffer.cpp | 9 +++++++++\n> > > > > src/libcamera/v4l2_videodevice.cpp | 1 +\n> > > > > 3 files changed, 11 insertions(+)\n> > > > >\n> > > > > diff --git a/include/libcamera/framebuffer.h b/include/libcamera/framebuffer.h\n> > > > > index ff8392430..fccfaa82a 100644\n> > > > > --- a/include/libcamera/framebuffer.h\n> > > > > +++ b/include/libcamera/framebuffer.h\n> > > > > @@ -34,6 +34,7 @@ struct FrameMetadata {\n> > > > >\n> > > > > Status status;\n> > > > > unsigned int sequence;\n> > > > > + unsigned int hwSequence;\n> > > > > uint64_t timestamp;\n> > > > >\n> > > > > Span planes() { return planes_; }\n> > > > > diff --git a/src/libcamera/framebuffer.cpp b/src/libcamera/framebuffer.cpp\n> > > > > index 826848f75..d9d6294bc 100644\n> > > > > --- a/src/libcamera/framebuffer.cpp\n> > > > > +++ b/src/libcamera/framebuffer.cpp\n> > > > > @@ -86,6 +86,15 @@ LOG_DEFINE_CATEGORY(Buffer)\n> > > > > * Gaps in the sequence numbers indicate dropped frames.\n> > > > > */\n> > > > >\n> > > > > +/**\n> > > > > + * \\var FrameMetadata::hwSequence\n> > > > > + * \\brief The real hardware Frame sequence number\n> > > >\n> > > > * \\brief The hardware frame sequence number as reported by the video device\n> > > > > + *\n> > > > > + * \\a FrameMetadata::sequence auto-corrects the initial value to zero on frame\n> > > >\n> > > > * V4L2VideoDevice::dequeueBuffer() auto-corrects\n> > > > * FrameMetadata::sequence to zero on stream start. This values\n> > > > * stores the non-corrected hardware sequence number as reported by\n> > > > * the video device.\n> > > > */\n> > > >\n> > > > Reviewed-by: Jacopo Mondi \n> > > >\n> > > > Thanks\n> > > > j\n> > > >\n> > > > > + * start. This value keeps the original hardware sequence to allow users to\n> > > > > + * query processing information of particular frames.\n> > > > > + */\n> > > > > +\n> > > > > /**\n> > > > > * \\var FrameMetadata::timestamp\n> > > > > * \\brief Time when the frame was captured\n> > > > > diff --git a/src/libcamera/v4l2_videodevice.cpp b/src/libcamera/v4l2_videodevice.cpp\n> > > > > index 14eba0561..9bc677edf 100644\n> > > > > --- a/src/libcamera/v4l2_videodevice.cpp\n> > > > > +++ b/src/libcamera/v4l2_videodevice.cpp\n> > > > > @@ -1862,6 +1862,7 @@ FrameBuffer *V4L2VideoDevice::dequeueBuffer()\n> > > > > ? FrameMetadata::FrameError\n> > > > > : FrameMetadata::FrameSuccess;\n> > > > > metadata.sequence = buf.sequence;\n> > > > > + metadata.hwSequence = buf.sequence;\n> > > > > metadata.timestamp = buf.timestamp.tv_sec * 1000000000ULL\n> > > > > + buf.timestamp.tv_usec * 1000ULL;\n> > > > >\n>\n> --\n> Regards,\n>\n> Laurent Pinchart","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 8E247C31E9\n\tfor ;\n\tFri, 29 Nov 2024 07:53:42 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id 03C4E65FFA;\n\tFri, 29 Nov 2024 08:53:42 +0100 (CET)","from perceval.ideasonboard.com (perceval.ideasonboard.com\n\t[213.167.242.64])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id D22DC60CE6\n\tfor ;\n\tFri, 29 Nov 2024 08:53:40 +0100 (CET)","from ideasonboard.com (unknown\n\t[IPv6:2001:b07:6462:5de2:459e:1ee6:26ea:2d31])\n\tby perceval.ideasonboard.com (Postfix) with ESMTPSA id 3418080A;\n\tFri, 29 Nov 2024 08:53:16 +0100 (CET)"],"Authentication-Results":"lancelot.ideasonboard.com; dkim=pass (1024-bit key;\n\tunprotected) header.d=ideasonboard.com header.i=@ideasonboard.com\n\theader.b=\"PCOtCHpK\"; dkim-atps=neutral","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com;\n\ts=mail; t=1732866796;\n\tbh=3xieYRD8yk1mcN+Vr0fI5oCDl/ZdgZnH4G2Q2NDCBis=;\n\th=Date:From:To:Cc:Subject:References:In-Reply-To:From;\n\tb=PCOtCHpKZatvX6epKOgn6iDGUoOj/jNq0KqZU2k2D6l3IxzsSkqbUWMhjNGr/13tj\n\t9JG+zCUlBDehsMx5CWdZYe3SICimMrhogJb6VEdDbjufIMNavGmyjpnk514Njw9meT\n\tgOhpuB2CVcB7ymlOiJv/2+ig+uerph2YxG+km2RA=","Date":"Fri, 29 Nov 2024 08:53:36 +0100","From":"Jacopo Mondi ","To":"Laurent Pinchart ","Cc":"Cheng-Hao Yang , \n\tKieran Bingham ,\n\tJacopo Mondi , \n\tlibcamera-devel@lists.libcamera.org,\n\tYudhistira Erlandinata ","Subject":"Re: [PATCH] libcamera: reserve frame sequence reported from the\n\thardware","Message-ID":"","References":"<20241016131730.3634805-1-chenghaoyang@chromium.org>\n\t\n\t<172937659347.2485972.8195423053247269678@ping.linuxembedded.co.uk>\n\t\n\t<20241128200144.GD25839@pendragon.ideasonboard.com>","MIME-Version":"1.0","Content-Type":"text/plain; charset=utf-8","Content-Disposition":"inline","Content-Transfer-Encoding":"8bit","In-Reply-To":"<20241128200144.GD25839@pendragon.ideasonboard.com>","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","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}},{"id":32451,"web_url":"https://patchwork.libcamera.org/comment/32451/","msgid":"","date":"2024-11-29T08:18:22","subject":"Re: [PATCH] libcamera: reserve frame sequence reported from the\n\thardware","submitter":{"id":117,"url":"https://patchwork.libcamera.org/api/people/117/","name":"Cheng-Hao Yang","email":"chenghaoyang@chromium.org"},"content":"Hi Laurent,\n\nOn Fri, Nov 29, 2024 at 3:53 PM Jacopo Mondi\n wrote:\n>\n> Hi Laurent\n>\n> On Thu, Nov 28, 2024 at 10:01:44PM +0200, Laurent Pinchart wrote:\n> > On Tue, Oct 22, 2024 at 01:48:46AM +0800, Cheng-Hao Yang wrote:\n> > > On Sun, Oct 20, 2024 at 6:23 AM Kieran Bingham wrote:\n> > > > Quoting Jacopo Mondi (2024-10-16 17:10:24)\n> > > > > On Wed, Oct 16, 2024 at 01:17:28PM +0000, Harvey Yang wrote:\n> > > > > > From: Yudhistira Erlandinata \n> > > > > >\n> > > > > > Originally libcamera resets the sequence to 0 on streamOn. However,\n> > > > > > However, there are occasions when the user needs the original\n> > > > >\n> > > > > However, there's one However too much\n> > >\n> > > Yes, sorry. I'll remove it in the next version.\n> > > If we decide to merge this one, please just remove it for me to avoid\n> > > the spam :)\n> > >\n> > > > > > hardware sequence to query processing information of the particular\n> > > > > > frame. The patch reserves the hwSequence in the FrameMetadata.\n> >\n> > What are the use cases for this ? The sequence number provided by V4L2\n> > is supposed to be internal only, why does it need to be exposed to\n> > applications ? Or is this meant for internal use only ? If so it\n> > shouldn't be exposed in the public API.\n\nIn mtkisp7's case, it's required for tuning, where they need the real frame\nnumbers.\n\nAs the tuning is already done, we might not need it. Not sure if it's required\nfor other devices' tuning as well though.\n\n\n> >\n>\n> We currently zero the sequence number\n> https://git.libcamera.org/libcamera/libcamera.git/tree/src/libcamera/v4l2_videodevice.cpp#n1871\n>\n> Please note getting somewhere back the 'real' frame number is relevant\n> for PFC as well.\n>\n> > > > > >\n> > > > > > Signed-off-by: Yudhistira Erlandinata \n> > > > > > Co-developed-by: Harvey Yang \n> > > > > > Signed-off-by: Harvey Yang \n> > > > >\n> > > > > I'm more on the opinion that we should stop zeroing the actual HW\n> > > > > sequences.\n> > > > >\n> > > > > Particularly, as we move towards a model where the camera pipeline\n> > > > > should be running even without buffers queued to the video capture\n> > > > > devices (iow producing frames from the sensor and stas from the ISP), an\n> > > > > application could queue a video buffer later, and we should be able to\n> > > > > detect how many frames have been \"missed\" and the existing\n> > > > >\n> > > > > if (!firstFrame_.has_value()) {\n> > > > >\n> > > > > check in V4L2VideoDevice::dequeueBuffer() will produce unwanted\n> > > > > Info messages.\n> > > > >\n> > > > > Kieran in cc as I recall this is something he introduced.\n> > > > >\n> > > > > In the meantime, storing the actual sequence number somewhere I think\n> > > > > it's fine.\n> > > >\n> > > > So - yes - I think 'knowing' the real hardware sequence number is a good\n> > > > thing probably. The original aim of my patch was to make it consistent\n> > > > from libcamera's perspective that frames start at zero... which I think\n> > > > is what drivers are /supposed/ to do.\n> > > >\n> > > > So not starting at zero is/was I think a kernel driver bug .. but alas\n> > > > they occur.\n> > > >\n> > > > And yes - the other side of this was to be able to try to align frame\n> > > > sequences for pfc ... but if we are going to handle that well then I\n> > > > wouldn't object to removing the zeroing or handling it in a different\n> > > > fashion - or simply continuing with a zero indexed base for applications\n> > > > and tracking\n> > >\n> > > I guess you're cut-off'ed again...?\n> > >\n> > > > I'd be curious to see what the device that needs this is doing at\n> > > > startup ... Do you always get a start at 1 ? or do you get starting\n> > > > offsets at 'random' values or something else ?\n> > >\n> > > I got some `1`s and `5`s. Seems quite consistent though, FYI.\n> >\n> > What device is that ?\n\nChromebook ciri with pipeline handler mtkisp7.\n\nBR,\nHarvey\n\n> >\n> > > > > > ---\n> > > > > > include/libcamera/framebuffer.h | 1 +\n> > > > > > src/libcamera/framebuffer.cpp | 9 +++++++++\n> > > > > > src/libcamera/v4l2_videodevice.cpp | 1 +\n> > > > > > 3 files changed, 11 insertions(+)\n> > > > > >\n> > > > > > diff --git a/include/libcamera/framebuffer.h b/include/libcamera/framebuffer.h\n> > > > > > index ff8392430..fccfaa82a 100644\n> > > > > > --- a/include/libcamera/framebuffer.h\n> > > > > > +++ b/include/libcamera/framebuffer.h\n> > > > > > @@ -34,6 +34,7 @@ struct FrameMetadata {\n> > > > > >\n> > > > > > Status status;\n> > > > > > unsigned int sequence;\n> > > > > > + unsigned int hwSequence;\n> > > > > > uint64_t timestamp;\n> > > > > >\n> > > > > > Span planes() { return planes_; }\n> > > > > > diff --git a/src/libcamera/framebuffer.cpp b/src/libcamera/framebuffer.cpp\n> > > > > > index 826848f75..d9d6294bc 100644\n> > > > > > --- a/src/libcamera/framebuffer.cpp\n> > > > > > +++ b/src/libcamera/framebuffer.cpp\n> > > > > > @@ -86,6 +86,15 @@ LOG_DEFINE_CATEGORY(Buffer)\n> > > > > > * Gaps in the sequence numbers indicate dropped frames.\n> > > > > > */\n> > > > > >\n> > > > > > +/**\n> > > > > > + * \\var FrameMetadata::hwSequence\n> > > > > > + * \\brief The real hardware Frame sequence number\n> > > > >\n> > > > > * \\brief The hardware frame sequence number as reported by the video device\n> > > > > > + *\n> > > > > > + * \\a FrameMetadata::sequence auto-corrects the initial value to zero on frame\n> > > > >\n> > > > > * V4L2VideoDevice::dequeueBuffer() auto-corrects\n> > > > > * FrameMetadata::sequence to zero on stream start. This values\n> > > > > * stores the non-corrected hardware sequence number as reported by\n> > > > > * the video device.\n> > > > > */\n> > > > >\n> > > > > Reviewed-by: Jacopo Mondi \n> > > > >\n> > > > > Thanks\n> > > > > j\n> > > > >\n> > > > > > + * start. This value keeps the original hardware sequence to allow users to\n> > > > > > + * query processing information of particular frames.\n> > > > > > + */\n> > > > > > +\n> > > > > > /**\n> > > > > > * \\var FrameMetadata::timestamp\n> > > > > > * \\brief Time when the frame was captured\n> > > > > > diff --git a/src/libcamera/v4l2_videodevice.cpp b/src/libcamera/v4l2_videodevice.cpp\n> > > > > > index 14eba0561..9bc677edf 100644\n> > > > > > --- a/src/libcamera/v4l2_videodevice.cpp\n> > > > > > +++ b/src/libcamera/v4l2_videodevice.cpp\n> > > > > > @@ -1862,6 +1862,7 @@ FrameBuffer *V4L2VideoDevice::dequeueBuffer()\n> > > > > > ? FrameMetadata::FrameError\n> > > > > > : FrameMetadata::FrameSuccess;\n> > > > > > metadata.sequence = buf.sequence;\n> > > > > > + metadata.hwSequence = buf.sequence;\n> > > > > > metadata.timestamp = buf.timestamp.tv_sec * 1000000000ULL\n> > > > > > + buf.timestamp.tv_usec * 1000ULL;\n> > > > > >\n> >\n> > --\n> > Regards,\n> >\n> > Laurent Pinchart","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 3358EC3220\n\tfor ;\n\tFri, 29 Nov 2024 08:18:48 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id 5D95465FFA;\n\tFri, 29 Nov 2024 09:18:47 +0100 (CET)","from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com\n\t[IPv6:2a00:1450:4864:20::22d])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id D8F0460CE6\n\tfor ;\n\tFri, 29 Nov 2024 09:18:44 +0100 (CET)","by mail-lj1-x22d.google.com with SMTP id\n\t38308e7fff4ca-2ffa3e8e917so18307211fa.3\n\tfor ;\n\tFri, 29 Nov 2024 00:18:44 -0800 (PST)"],"Authentication-Results":"lancelot.ideasonboard.com; dkim=pass (1024-bit key;\n\tunprotected) header.d=chromium.org header.i=@chromium.org\n\theader.b=\"f/8312sk\"; dkim-atps=neutral","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=chromium.org; s=google; t=1732868324; x=1733473124;\n\tdarn=lists.libcamera.org; \n\th=content-transfer-encoding:cc:to:subject:message-id:date:from\n\t:in-reply-to:references:mime-version:from:to:cc:subject:date\n\t:message-id:reply-to;\n\tbh=DLLYrLJ2LVV66ucCi11Q25BtV9C6uFrNkwfNdsju8Io=;\n\tb=f/8312sk+jqAIRpjxDDyYBsN7WpOy27HM7UDxjNXc5Jt9UuTbP2uL2Ko/UnzZN+XBR\n\tOuK2oRB5wAGwnRg6KGaFny8GU1fQWf87l/ZdN9QriGIUCm63VPmFcIt68p1CAcePCmmO\n\ttce6V3Do/hSmhV1fC3UXcUstAqFmXVRUKZxKs=","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20230601; t=1732868324; x=1733473124;\n\th=content-transfer-encoding:cc:to:subject:message-id:date:from\n\t:in-reply-to:references:mime-version:x-gm-message-state:from:to:cc\n\t:subject:date:message-id:reply-to;\n\tbh=DLLYrLJ2LVV66ucCi11Q25BtV9C6uFrNkwfNdsju8Io=;\n\tb=UzeuPG9O5WSG3E+EGV6wzWRvr1zU5HRsTuAR+1BNqvuvBeQwcLKs4VwF9+AU8APC1i\n\tHDOWW8g2mrY91CFT5ywAFY6bYXc7VsNOnzNKKYxspmqoc4DZK4aC2T6xs1sPZMFC8/8X\n\tXooFl7GaUowyOwZ9qVbSAQsvpm+d8s+emgDUG30oHnfE2mLoRnNyKKXkP+xAnVBPOd6z\n\tjkA3fBdE3a71CWnfxrVsrdhri8qbPyljS5amdjsq9bwNZ92fKFlyCIPyLWu+2xHccm1z\n\tp0wKCXvVAhrv/gGdxF+fYsu3qxDZE64n9aRUvJjlhjALkg1c/+IURCyQ4BUJOj3Um+QC\n\tEqNg==","X-Forwarded-Encrypted":"i=1;\n\tAJvYcCVrHnTf10CvSqhbflf+U3vMS5cP7C+c6BfjLSb12aHu/ois66ceoUkEGkNNEKyi9gcoTQAnEKaZIdSPJHivJKc=@lists.libcamera.org","X-Gm-Message-State":"AOJu0Yx83smeQyz4bN1IHCZsevwEpE5A+MufFBCcG6VYqhWHzfH1k6rB\n\tz0r4kZiFxxi679y7MxgJByKiLWS429DXU/MvkdiCKrjK0VPw+wkfq70SiGOPKgRxZ5+G5+Z9QP5\n\toAdpWmH+XIkjygkq6vZtjuXnM+yq3OX+JEXJr","X-Gm-Gg":"ASbGncuaJ3qZq80XNj+K4kJxszbCbSevE1MUgEsXhu14c3NmvLber3jO4UUp5tKVfOc\n\tnqYTgZBLVvAj+8beaGEDlO6MV27MDfkKf7VHBngf1JCLh/1cbF3cWDnkNnNs=","X-Google-Smtp-Source":"AGHT+IEddHp8cjzdlljVmFH6cwywlGnZVDduy1YtWOUBOvT/qErbVe90zePTYDOmmflB9U9wjykFgFYJJwaSS/nN4LM=","X-Received":"by 2002:a2e:bd12:0:b0:2ff:c772:69c4 with SMTP id\n\t38308e7fff4ca-2ffd60dc709mr65281151fa.23.1732868323686;\n\tFri, 29 Nov 2024 00:18:43 -0800 (PST)","MIME-Version":"1.0","References":"<20241016131730.3634805-1-chenghaoyang@chromium.org>\n\t\n\t<172937659347.2485972.8195423053247269678@ping.linuxembedded.co.uk>\n\t\n\t<20241128200144.GD25839@pendragon.ideasonboard.com>\n\t","In-Reply-To":"","From":"Cheng-Hao Yang ","Date":"Fri, 29 Nov 2024 16:18:22 +0800","Message-ID":"","Subject":"Re: [PATCH] libcamera: reserve frame sequence reported from the\n\thardware","To":"Jacopo Mondi ","Cc":"Laurent Pinchart , \n\tKieran Bingham ,\n\tlibcamera-devel@lists.libcamera.org, \n\tYudhistira Erlandinata ","Content-Type":"text/plain; charset=\"UTF-8\"","Content-Transfer-Encoding":"quoted-printable","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","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}}]