[{"id":21618,"web_url":"https://patchwork.libcamera.org/comment/21618/","msgid":"","date":"2021-12-07T00:07:26","subject":"Re: [libcamera-devel] [RFC PATCH 0/8] Request metadata:\n\tSensorSequence","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 patches.\n\nOn Mon, Dec 06, 2021 at 11:39:40PM +0000, Kieran Bingham wrote:\n> When completing a request, the individual stream buffers contain a\n> sequence number. This number is generated by the device that ultimately\n> fills that stream, but it might not be the sensor. Processing through an\n> ISP could cause the sequence numbers and timestamp data associated with\n> the completed buffer to be values representative of the ISP processing\n> rather than the (intended) capture device.\n> \n> Provide a new metadata control, still to be fully sketched out which\n> gives us a defined value to report the Camera sequence number. This\n> allows pipeline handlers to correctly set the value according to the\n> device that represents the capture from the sensor.\n> \n> This plumbing then allows applications to detect frame drops, which were\n> otherwise going unnoticed, and as such some basic additions have been\n> made to cam, qcam, and gstreamer to support this new data.\n> \n> Still possible:\n> - Adding a validation to lc-compliance to make sure pipelines set the\n> SensorSequence on every frame.\n> \n> - Probably expecting some better gstreamer event integration perhaps? \n> \n> - qcam should report more statistics on the processing overall\n> \n> - libcamera Tracepoints could be added as an event to track when\n> frames are detected as dropped by the core framework.\n> \n> Anything else?\n\nA basic design question: when a frame is dropped, shouldn't we report\nthe corresponding request as failed ? That's how the Android camera HAL\nAPI operates, and while that by itself isn't a good enough reason to do\nthat same, I think it offers a better way to ensure that controls get\nsynchronized with the buffers that frames are captured to.\n\n> Kieran Bingham (8):\n> libcamera: controls: Add SensorSequence metadata control\n> libcamera: pipeline: Set the Sensor sequence number for all pipelines\n> cam: Use SensorTimestamp rather than buffer metadata\n> cam: Use Sensor sequence numbers and detect frame drop\n> qcam: main_window: Fix include ordering\n> qcam: Use Sensor sequence numbers and detect frame drop\n> gstreamer: gstlibcamerasrc: Fix include ordering\n> gstreamer: Use Sensor sequence numbers and detect frame drop\n> \n> src/cam/camera_session.cpp | 24 ++++++++--\n> src/cam/camera_session.h | 1 +\n> src/gstreamer/gstlibcamerasrc.cpp | 46 +++++++++++++++----\n> src/libcamera/control_ids.yaml | 8 ++++\n> src/libcamera/pipeline/ipu3/ipu3.cpp | 4 +-\n> .../pipeline/raspberrypi/raspberrypi.cpp | 3 ++\n> src/libcamera/pipeline/rkisp1/rkisp1.cpp | 4 +-\n> src/libcamera/pipeline/simple/simple.cpp | 12 +++--\n> src/libcamera/pipeline/uvcvideo/uvcvideo.cpp | 2 +\n> src/qcam/main_window.cpp | 28 +++++++++--\n> src/qcam/main_window.h | 1 +\n> 11 files changed, 111 insertions(+), 22 deletions(-)","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 909DEBDB13\n\tfor ;\n\tTue, 7 Dec 2021 00:07:58 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id D84B96086C;\n\tTue, 7 Dec 2021 01:07: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 13BB960117\n\tfor ;\n\tTue, 7 Dec 2021 01:07:56 +0100 (CET)","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 26ACF556;\n\tTue, 7 Dec 2021 01:07:54 +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=\"EPsYRjRM\"; dkim-atps=neutral","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com;\n\ts=mail; t=1638835675;\n\tbh=CYSaDVeJgAMxpwgjuIPam4ub0E0zXbmMaCA5Gn2qX98=;\n\th=Date:From:To:Cc:Subject:References:In-Reply-To:From;\n\tb=EPsYRjRMPVZVLsXkJBEiDF00woci5RVjY8qsxeU/Hyl57BHupyv1SQ4Q37ZqFYrNa\n\ttQsfYWETuSwd3RbGKkjgiFcFdUEaplJT8TYAVZJWJ9d8paHELP7pjcf3S2rV8V/Yhy\n\tTMnFo6H8GZpu4zXF1lrFG7O0Y3C2VNIyre714Q4g=","Date":"Tue, 7 Dec 2021 02:07:26 +0200","From":"Laurent Pinchart ","To":"Kieran Bingham ","Message-ID":"","References":"<20211206233948.1351206-1-kieran.bingham@ideasonboard.com>","MIME-Version":"1.0","Content-Type":"text/plain; charset=utf-8","Content-Disposition":"inline","In-Reply-To":"<20211206233948.1351206-1-kieran.bingham@ideasonboard.com>","Subject":"Re: [libcamera-devel] [RFC PATCH 0/8] Request metadata:\n\tSensorSequence","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 ","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}},{"id":21623,"web_url":"https://patchwork.libcamera.org/comment/21623/","msgid":"","date":"2021-12-07T08:42:36","subject":"Re: [libcamera-devel] [RFC PATCH 0/8] Request metadata:\n\tSensorSequence","submitter":{"id":34,"url":"https://patchwork.libcamera.org/api/people/34/","name":"Naushir Patuck","email":"naush@raspberrypi.com"},"content":"Hi Kieran and Laurent,\n\n\nOn Tue, 7 Dec 2021 at 00:07, Laurent Pinchart <\nlaurent.pinchart@ideasonboard.com> wrote:\n\n> Hi Kieran,\n>\n> Thank you for the patches.\n>\n> On Mon, Dec 06, 2021 at 11:39:40PM +0000, Kieran Bingham wrote:\n> > When completing a request, the individual stream buffers contain a\n> > sequence number. This number is generated by the device that ultimately\n> > fills that stream, but it might not be the sensor. Processing through an\n> > ISP could cause the sequence numbers and timestamp data associated with\n> > the completed buffer to be values representative of the ISP processing\n> > rather than the (intended) capture device.\n> >\n> > Provide a new metadata control, still to be fully sketched out which\n> > gives us a defined value to report the Camera sequence number. This\n> > allows pipeline handlers to correctly set the value according to the\n> > device that represents the capture from the sensor.\n> >\n> > This plumbing then allows applications to detect frame drops, which were\n> > otherwise going unnoticed, and as such some basic additions have been\n> > made to cam, qcam, and gstreamer to support this new data.\n> >\n> > Still possible:\n> > - Adding a validation to lc-compliance to make sure pipelines set the\n> > SensorSequence on every frame.\n> >\n> > - Probably expecting some better gstreamer event integration perhaps?\n> >\n> > - qcam should report more statistics on the processing overall\n> >\n> > - libcamera Tracepoints could be added as an event to track when\n> > frames are detected as dropped by the core framework.\n> >\n> > Anything else?\n>\n> A basic design question: when a frame is dropped, shouldn't we report\n> the corresponding request as failed ? That's how the Android camera HAL\n> API operates, and while that by itself isn't a good enough reason to do\n> that same, I think it offers a better way to ensure that controls get\n> synchronized with the buffers that frames are captured to.\n>\n\nFor the Raspberry Pi platforms, it is possible for the Unicam driver\nto drop frames without the knowledge of the pipeline handler, if for example\nwe do not recycle bayer buffers quick enough. Allowing the application\nto look at sensor timestamps would allow it to detect these drops. Unless\nI am mistaken, this would not be possible by failing the request, as the\nsensor buffer recycling loop is asynchronous to the application request\nloop. Having said that, they could be synchronised....\n\nRegards,\nNaush\n\n\n>\n> > Kieran Bingham (8):\n> > libcamera: controls: Add SensorSequence metadata control\n> > libcamera: pipeline: Set the Sensor sequence number for all pipelines\n> > cam: Use SensorTimestamp rather than buffer metadata\n> > cam: Use Sensor sequence numbers and detect frame drop\n> > qcam: main_window: Fix include ordering\n> > qcam: Use Sensor sequence numbers and detect frame drop\n> > gstreamer: gstlibcamerasrc: Fix include ordering\n> > gstreamer: Use Sensor sequence numbers and detect frame drop\n> >\n> > src/cam/camera_session.cpp | 24 ++++++++--\n> > src/cam/camera_session.h | 1 +\n> > src/gstreamer/gstlibcamerasrc.cpp | 46 +++++++++++++++----\n> > src/libcamera/control_ids.yaml | 8 ++++\n> > src/libcamera/pipeline/ipu3/ipu3.cpp | 4 +-\n> > .../pipeline/raspberrypi/raspberrypi.cpp | 3 ++\n> > src/libcamera/pipeline/rkisp1/rkisp1.cpp | 4 +-\n> > src/libcamera/pipeline/simple/simple.cpp | 12 +++--\n> > src/libcamera/pipeline/uvcvideo/uvcvideo.cpp | 2 +\n> > src/qcam/main_window.cpp | 28 +++++++++--\n> > src/qcam/main_window.h | 1 +\n> > 11 files changed, 111 insertions(+), 22 deletions(-)\n>\n> --\n> Regards,\n>\n> Laurent Pinchart\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 32C1ABF415\n\tfor ;\n\tTue, 7 Dec 2021 08:42:57 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id 55717607DE;\n\tTue, 7 Dec 2021 09:42:56 +0100 (CET)","from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com\n\t[IPv6:2a00:1450:4864:20::12a])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id C71D96059E\n\tfor ;\n\tTue, 7 Dec 2021 09:42:53 +0100 (CET)","by mail-lf1-x12a.google.com with SMTP id l22so31828570lfg.7\n\tfor ;\n\tTue, 07 Dec 2021 00:42:53 -0800 (PST)"],"Authentication-Results":"lancelot.ideasonboard.com;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=raspberrypi.com header.i=@raspberrypi.com\n\theader.b=\"Cq//zY7A\"; dkim-atps=neutral","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=raspberrypi.com; s=google;\n\th=mime-version:references:in-reply-to:from:date:message-id:subject:to\n\t:cc; bh=tSOwztQsYLFofNFpeBL8DYCEIwf8OzHP4IY2pj9T1H8=;\n\tb=Cq//zY7AHlvGwGGP2zMr/9IM/7SuteloDknqG9PXG/8bEHa2nRHTdstaR688cLhdwn\n\t3kCavYS0kOHVJLgFU2zK87S70JbVYbKt7pNYcnz5c46c0sa09YjG0PGOA04dBs3eH53m\n\t/FWF0/O5lPcaN6cVACmuvx3PyVKRwa+1ZmM2SFWSQkUKoNOIrnKPzo/rLUF0hkXM3tkR\n\tUB23yWMD12Yz8OPzMh6min4xfK9NYarn5xg6t3O1R4yljDaUtddVNsxjOAV7Zj5N2SGI\n\tYk+uMqqZpVVcgFukrJxx4mSro9MjXaxnLQ3fdEPkcLlAo5i2I+KLg9unb9TiFVl5j+kL\n\tzdjQ==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20210112;\n\th=x-gm-message-state:mime-version:references:in-reply-to:from:date\n\t:message-id:subject:to:cc;\n\tbh=tSOwztQsYLFofNFpeBL8DYCEIwf8OzHP4IY2pj9T1H8=;\n\tb=QsU/2lNRyyf+JujNVCimnYpqWiVYt17cyOzQi089QdNAFsLbS+PAV6dM5nHUfAjRpw\n\t86oRc4Z8c39HiKrj5xBUcjSX1jKzMou7uUFuAK3hnSJ11LM9vxjToWWjbUdrE0IRiFF1\n\tn0m0isKITW7YVoSry9qfqbpEmOA35DuCLiu4xZ6bJu1NP/7LkzpkW0rrsvpr16Bmhxi5\n\t4XG8YEkor3647/EM5vFrlqEfGhzRXRxYs7vYDbUQWtSN7rqXWd5Ggdxcf3Gnvu4Dv97r\n\t2HQ6hitWFfzE4rXRdFoAAiJwbIklhhhfwq1oJlsAMEo/XMbB5e7igRr7+/wrmeZSuiSX\n\teQpQ==","X-Gm-Message-State":"AOAM533Mz5hgCCDk+414pN3ydU27+0kMFEQZxCSFCz+Yd9u1oPiKokli\n\t3UC5/d1apizxzXtExoXiqf5QeLqqJiDJ0hKTlApgfQbBc9Eymg==","X-Google-Smtp-Source":"ABdhPJxyrpMl101gDR6hRhaHyz2miSnqAOii8jT4UMpDfuEpP7XNcRMvUoKlSWEYhlalYEmp6BgXWZmAgUFsNHbQ7+M=","X-Received":"by 2002:a05:6512:150c:: with SMTP id\n\tbq12mr40951379lfb.687.1638866572811; \n\tTue, 07 Dec 2021 00:42:52 -0800 (PST)","MIME-Version":"1.0","References":"<20211206233948.1351206-1-kieran.bingham@ideasonboard.com>\n\t","In-Reply-To":"","From":"Naushir Patuck ","Date":"Tue, 7 Dec 2021 08:42:36 +0000","Message-ID":"","To":"Laurent Pinchart ","Content-Type":"multipart/alternative; boundary=\"000000000000e82ee405d28a5b4c\"","Subject":"Re: [libcamera-devel] [RFC PATCH 0/8] Request metadata:\n\tSensorSequence","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 ","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}},{"id":21644,"web_url":"https://patchwork.libcamera.org/comment/21644/","msgid":"","date":"2021-12-07T14:21:34","subject":"Re: [libcamera-devel] [RFC PATCH 0/8] Request metadata:\n\tSensorSequence","submitter":{"id":2,"url":"https://patchwork.libcamera.org/api/people/2/","name":"Laurent Pinchart","email":"laurent.pinchart@ideasonboard.com"},"content":"Hi Naush,\n\nOn Tue, Dec 07, 2021 at 08:42:36AM +0000, Naushir Patuck wrote:\n> On Tue, 7 Dec 2021 at 00:07, Laurent Pinchart wrote:\n> > On Mon, Dec 06, 2021 at 11:39:40PM +0000, Kieran Bingham wrote:\n> > > When completing a request, the individual stream buffers contain a\n> > > sequence number. This number is generated by the device that ultimately\n> > > fills that stream, but it might not be the sensor. Processing through an\n> > > ISP could cause the sequence numbers and timestamp data associated with\n> > > the completed buffer to be values representative of the ISP processing\n> > > rather than the (intended) capture device.\n> > >\n> > > Provide a new metadata control, still to be fully sketched out which\n> > > gives us a defined value to report the Camera sequence number. This\n> > > allows pipeline handlers to correctly set the value according to the\n> > > device that represents the capture from the sensor.\n> > >\n> > > This plumbing then allows applications to detect frame drops, which were\n> > > otherwise going unnoticed, and as such some basic additions have been\n> > > made to cam, qcam, and gstreamer to support this new data.\n> > >\n> > > Still possible:\n> > > - Adding a validation to lc-compliance to make sure pipelines set the\n> > > SensorSequence on every frame.\n> > >\n> > > - Probably expecting some better gstreamer event integration perhaps?\n> > >\n> > > - qcam should report more statistics on the processing overall\n> > >\n> > > - libcamera Tracepoints could be added as an event to track when\n> > > frames are detected as dropped by the core framework.\n> > >\n> > > Anything else?\n> >\n> > A basic design question: when a frame is dropped, shouldn't we report\n> > the corresponding request as failed ? That's how the Android camera HAL\n> > API operates, and while that by itself isn't a good enough reason to do\n> > that same, I think it offers a better way to ensure that controls get\n> > synchronized with the buffers that frames are captured to.\n> \n> For the Raspberry Pi platforms, it is possible for the Unicam driver\n> to drop frames without the knowledge of the pipeline handler, if for example\n> we do not recycle bayer buffers quick enough.\n\nSo the driver doesn't increment the sequence number in that case ? Could\nthis be fixed ?\n\n> Allowing the application\n> to look at sensor timestamps would allow it to detect these drops. Unless\n> I am mistaken, this would not be possible by failing the request, as the\n> sensor buffer recycling loop is asynchronous to the application request\n> loop. Having said that, they could be synchronised....\n\nThis is also related to implementing true per-frame control,\nsynchronizing the controls from the request with the buffers in which\nimages are captured :-)\n\n> > > Kieran Bingham (8):\n> > > libcamera: controls: Add SensorSequence metadata control\n> > > libcamera: pipeline: Set the Sensor sequence number for all pipelines\n> > > cam: Use SensorTimestamp rather than buffer metadata\n> > > cam: Use Sensor sequence numbers and detect frame drop\n> > > qcam: main_window: Fix include ordering\n> > > qcam: Use Sensor sequence numbers and detect frame drop\n> > > gstreamer: gstlibcamerasrc: Fix include ordering\n> > > gstreamer: Use Sensor sequence numbers and detect frame drop\n> > >\n> > > src/cam/camera_session.cpp | 24 ++++++++--\n> > > src/cam/camera_session.h | 1 +\n> > > src/gstreamer/gstlibcamerasrc.cpp | 46 +++++++++++++++----\n> > > src/libcamera/control_ids.yaml | 8 ++++\n> > > src/libcamera/pipeline/ipu3/ipu3.cpp | 4 +-\n> > > .../pipeline/raspberrypi/raspberrypi.cpp | 3 ++\n> > > src/libcamera/pipeline/rkisp1/rkisp1.cpp | 4 +-\n> > > src/libcamera/pipeline/simple/simple.cpp | 12 +++--\n> > > src/libcamera/pipeline/uvcvideo/uvcvideo.cpp | 2 +\n> > > src/qcam/main_window.cpp | 28 +++++++++--\n> > > src/qcam/main_window.h | 1 +\n> > > 11 files changed, 111 insertions(+), 22 deletions(-)","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 DBC9EBDB13\n\tfor ;\n\tTue, 7 Dec 2021 14:22:05 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id 0E49A60872;\n\tTue, 7 Dec 2021 15:22:05 +0100 (CET)","from perceval.ideasonboard.com (perceval.ideasonboard.com\n\t[213.167.242.64])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id C74DB60592\n\tfor ;\n\tTue, 7 Dec 2021 15:22:03 +0100 (CET)","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 3E0B0556;\n\tTue, 7 Dec 2021 15:22:03 +0100 (CET)"],"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=\"roMk+34a\"; dkim-atps=neutral","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com;\n\ts=mail; t=1638886923;\n\tbh=THsklHQ2TEA7eM+Dz6iSnrW0tcNRN/Rl0oUo58BTR+Y=;\n\th=Date:From:To:Cc:Subject:References:In-Reply-To:From;\n\tb=roMk+34a3IUdK8v1/8xcH87pbmfn4bD7AwGwelfFBE6SMLe4kBsktT7rrm6AiaNGo\n\tjmlBHixCGp2ijrNGWPmaT9FmKFyHLU0/dYbtBzHyKnOWlApmayPjGRFwE++CN09Rco\n\tAmRDtgLazb0hJOpcnXVLIlZtCwxSXDea5XOjKuiE=","Date":"Tue, 7 Dec 2021 16:21:34 +0200","From":"Laurent Pinchart ","To":"Naushir Patuck ","Message-ID":"","References":"<20211206233948.1351206-1-kieran.bingham@ideasonboard.com>\n\t\n\t","MIME-Version":"1.0","Content-Type":"text/plain; charset=utf-8","Content-Disposition":"inline","In-Reply-To":"","Subject":"Re: [libcamera-devel] [RFC PATCH 0/8] Request metadata:\n\tSensorSequence","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 ","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}},{"id":21646,"web_url":"https://patchwork.libcamera.org/comment/21646/","msgid":"","date":"2021-12-07T15:15:23","subject":"Re: [libcamera-devel] [RFC PATCH 0/8] Request metadata:\n\tSensorSequence","submitter":{"id":34,"url":"https://patchwork.libcamera.org/api/people/34/","name":"Naushir Patuck","email":"naush@raspberrypi.com"},"content":"Hi Laurent,\n\nOn Tue, 7 Dec 2021 at 14:22, Laurent Pinchart <\nlaurent.pinchart@ideasonboard.com> wrote:\n\n> Hi Naush,\n>\n> On Tue, Dec 07, 2021 at 08:42:36AM +0000, Naushir Patuck wrote:\n> > On Tue, 7 Dec 2021 at 00:07, Laurent Pinchart wrote:\n> > > On Mon, Dec 06, 2021 at 11:39:40PM +0000, Kieran Bingham wrote:\n> > > > When completing a request, the individual stream buffers contain a\n> > > > sequence number. This number is generated by the device that\n> ultimately\n> > > > fills that stream, but it might not be the sensor. Processing\n> through an\n> > > > ISP could cause the sequence numbers and timestamp data associated\n> with\n> > > > the completed buffer to be values representative of the ISP\n> processing\n> > > > rather than the (intended) capture device.\n> > > >\n> > > > Provide a new metadata control, still to be fully sketched out which\n> > > > gives us a defined value to report the Camera sequence number. This\n> > > > allows pipeline handlers to correctly set the value according to the\n> > > > device that represents the capture from the sensor.\n> > > >\n> > > > This plumbing then allows applications to detect frame drops, which\n> were\n> > > > otherwise going unnoticed, and as such some basic additions have been\n> > > > made to cam, qcam, and gstreamer to support this new data.\n> > > >\n> > > > Still possible:\n> > > > - Adding a validation to lc-compliance to make sure pipelines set\n> the\n> > > > SensorSequence on every frame.\n> > > >\n> > > > - Probably expecting some better gstreamer event integration\n> perhaps?\n> > > >\n> > > > - qcam should report more statistics on the processing overall\n> > > >\n> > > > - libcamera Tracepoints could be added as an event to track when\n> > > > frames are detected as dropped by the core framework.\n> > > >\n> > > > Anything else?\n> > >\n> > > A basic design question: when a frame is dropped, shouldn't we report\n> > > the corresponding request as failed ? That's how the Android camera HAL\n> > > API operates, and while that by itself isn't a good enough reason to do\n> > > that same, I think it offers a better way to ensure that controls get\n> > > synchronized with the buffers that frames are captured to.\n> >\n> > For the Raspberry Pi platforms, it is possible for the Unicam driver\n> > to drop frames without the knowledge of the pipeline handler, if for\n> example\n> > we do not recycle bayer buffers quick enough.\n>\n> So the driver doesn't increment the sequence number in that case ? Could\n> this be fixed ?\n>\n\nThe driver increments sequence numbers based on frame interrupts, so they\nchange even if the frame is going to be dropped.\n\n\n>\n> > Allowing the application\n> > to look at sensor timestamps would allow it to detect these drops. Unless\n> > I am mistaken, this would not be possible by failing the request, as the\n> > sensor buffer recycling loop is asynchronous to the application request\n> > loop. Having said that, they could be synchronised....\n>\n> This is also related to implementing true per-frame control,\n> synchronizing the controls from the request with the buffers in which\n> images are captured :-)\n>\n\nAs long as they are ISP based controls we are fine :-)\n\nRegards,\nNaush\n\n\n>\n> > > > Kieran Bingham (8):\n> > > > libcamera: controls: Add SensorSequence metadata control\n> > > > libcamera: pipeline: Set the Sensor sequence number for all\n> pipelines\n> > > > cam: Use SensorTimestamp rather than buffer metadata\n> > > > cam: Use Sensor sequence numbers and detect frame drop\n> > > > qcam: main_window: Fix include ordering\n> > > > qcam: Use Sensor sequence numbers and detect frame drop\n> > > > gstreamer: gstlibcamerasrc: Fix include ordering\n> > > > gstreamer: Use Sensor sequence numbers and detect frame drop\n> > > >\n> > > > src/cam/camera_session.cpp | 24 ++++++++--\n> > > > src/cam/camera_session.h | 1 +\n> > > > src/gstreamer/gstlibcamerasrc.cpp | 46\n> +++++++++++++++----\n> > > > src/libcamera/control_ids.yaml | 8 ++++\n> > > > src/libcamera/pipeline/ipu3/ipu3.cpp | 4 +-\n> > > > .../pipeline/raspberrypi/raspberrypi.cpp | 3 ++\n> > > > src/libcamera/pipeline/rkisp1/rkisp1.cpp | 4 +-\n> > > > src/libcamera/pipeline/simple/simple.cpp | 12 +++--\n> > > > src/libcamera/pipeline/uvcvideo/uvcvideo.cpp | 2 +\n> > > > src/qcam/main_window.cpp | 28 +++++++++--\n> > > > src/qcam/main_window.h | 1 +\n> > > > 11 files changed, 111 insertions(+), 22 deletions(-)\n>\n> --\n> Regards,\n>\n> Laurent Pinchart\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 E070FBF415\n\tfor ;\n\tTue, 7 Dec 2021 15:15:43 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id 44283605C4;\n\tTue, 7 Dec 2021 16:15:43 +0100 (CET)","from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com\n\t[IPv6:2a00:1450:4864:20::22f])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id 4C1B460592\n\tfor ;\n\tTue, 7 Dec 2021 16:15:41 +0100 (CET)","by mail-lj1-x22f.google.com with SMTP id v15so28134495ljc.0\n\tfor ;\n\tTue, 07 Dec 2021 07:15:41 -0800 (PST)"],"Authentication-Results":"lancelot.ideasonboard.com;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=raspberrypi.com header.i=@raspberrypi.com\n\theader.b=\"FpVdNA1B\"; dkim-atps=neutral","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=raspberrypi.com; s=google;\n\th=mime-version:references:in-reply-to:from:date:message-id:subject:to\n\t:cc; bh=sOvzkyHP5mg/cv7sRL3raB6nga9TtN1ppXQrf1l2x6o=;\n\tb=FpVdNA1BI0udo1YCOUDVaMNd0v64G9vunSTMAzxqNeieny5M00wSbt/SuwKNbQzy/a\n\t2XXSFzTmaXlvNX0m5AfGlxuvRRIE6MwjPHlfpKa6ZFPWEPbXbSsyyTwXjwtzsaNMnHf+\n\tix8l15y7JPIiRIR9Co5c7vt0vjoQm+Otn/rneYcNM2eSfZxDs22WG/bqOs+95stOLXBl\n\tnowKQcY6mUYA6eK7bDvII7DCudYwaW5boaR3drSpypozo1qXNyyvijkfHxmQ+9drBvH6\n\tHFVRvb7Lq++l7u/E4w6o+omVrqgkgZajwpcRgbKuf6Gl8UGEbcIl2KzwMV5CRKk/He0d\n\t5RWA==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20210112;\n\th=x-gm-message-state:mime-version:references:in-reply-to:from:date\n\t:message-id:subject:to:cc;\n\tbh=sOvzkyHP5mg/cv7sRL3raB6nga9TtN1ppXQrf1l2x6o=;\n\tb=UbX/jkOqK1SJDf/0spW1Ybn4dugJxDlmKiXeMatmzLycYf0RKxTP4j7ZbuIdsAZasO\n\thDNwMW8jKB03C+J/UMOWJrMT7JQ7b3W1qHLCexWDK0ZQySUvifNwgnDLWtc26u3C9/Cp\n\tfGz9hFw6cxDYYQbmZPHB8sR3XDrwL5syTRIKlb91pmHeC0drJM4IqYwYquW/nQp4BruK\n\tX31ovC6OQ8cysWblMTYeMWVT1mLreUu1yeq9/fu7nn77cGEdoEJh7MLIsvRe+3tCQBzQ\n\teI/bspluEKA0mDqLgurrCeJsVgd7CoX4Sn4k+7/q4eo4bVEyIuz8+r/hZ1o2sRDmTUd3\n\taxMg==","X-Gm-Message-State":"AOAM531dfnB5iQmasST3Ih06eMltpO0bMK1zcOfqoGIB7+nKFTHYyHdr\n\trzgkqtAg5G3cTktCND6a1SZsdye4Mr5LY+fjMfQ62nkiWjj/jg==","X-Google-Smtp-Source":"ABdhPJzboxCPzlwicwLiF7ufxxrA0wOBBD+NgbvgLJ/aC35e8fphHptpdvdGAT5+x8bV7weUyDHIlV48O2pYJFvxWuA=","X-Received":"by 2002:a2e:9196:: with SMTP id\n\tf22mr1177403ljg.444.1638890139046; \n\tTue, 07 Dec 2021 07:15:39 -0800 (PST)","MIME-Version":"1.0","References":"<20211206233948.1351206-1-kieran.bingham@ideasonboard.com>\n\t\n\t\n\t","In-Reply-To":"","From":"Naushir Patuck ","Date":"Tue, 7 Dec 2021 15:15:23 +0000","Message-ID":"","To":"Laurent Pinchart ","Content-Type":"multipart/alternative; boundary=\"000000000000906c9105d28fd830\"","Subject":"Re: [libcamera-devel] [RFC PATCH 0/8] Request metadata:\n\tSensorSequence","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 ","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}},{"id":21651,"web_url":"https://patchwork.libcamera.org/comment/21651/","msgid":"","date":"2021-12-07T16:47:26","subject":"Re: [libcamera-devel] [RFC PATCH 0/8] Request metadata:\n\tSensorSequence","submitter":{"id":2,"url":"https://patchwork.libcamera.org/api/people/2/","name":"Laurent Pinchart","email":"laurent.pinchart@ideasonboard.com"},"content":"Hi Naush,\n\nOn Tue, Dec 07, 2021 at 03:15:23PM +0000, Naushir Patuck wrote:\n> On Tue, 7 Dec 2021 at 14:22, Laurent Pinchart wrote:\n> > On Tue, Dec 07, 2021 at 08:42:36AM +0000, Naushir Patuck wrote:\n> > > On Tue, 7 Dec 2021 at 00:07, Laurent Pinchart wrote:\n> > > > On Mon, Dec 06, 2021 at 11:39:40PM +0000, Kieran Bingham wrote:\n> > > > > When completing a request, the individual stream buffers contain a\n> > > > > sequence number. This number is generated by the device that ultimately\n> > > > > fills that stream, but it might not be the sensor. Processing through an\n> > > > > ISP could cause the sequence numbers and timestamp data associated with\n> > > > > the completed buffer to be values representative of the ISP processing\n> > > > > rather than the (intended) capture device.\n> > > > >\n> > > > > Provide a new metadata control, still to be fully sketched out which\n> > > > > gives us a defined value to report the Camera sequence number. This\n> > > > > allows pipeline handlers to correctly set the value according to the\n> > > > > device that represents the capture from the sensor.\n> > > > >\n> > > > > This plumbing then allows applications to detect frame drops, which were\n> > > > > otherwise going unnoticed, and as such some basic additions have been\n> > > > > made to cam, qcam, and gstreamer to support this new data.\n> > > > >\n> > > > > Still possible:\n> > > > > - Adding a validation to lc-compliance to make sure pipelines set the\n> > > > > SensorSequence on every frame.\n> > > > >\n> > > > > - Probably expecting some better gstreamer event integration perhaps?\n> > > > >\n> > > > > - qcam should report more statistics on the processing overall\n> > > > >\n> > > > > - libcamera Tracepoints could be added as an event to track when\n> > > > > frames are detected as dropped by the core framework.\n> > > > >\n> > > > > Anything else?\n> > > >\n> > > > A basic design question: when a frame is dropped, shouldn't we report\n> > > > the corresponding request as failed ? That's how the Android camera HAL\n> > > > API operates, and while that by itself isn't a good enough reason to do\n> > > > that same, I think it offers a better way to ensure that controls get\n> > > > synchronized with the buffers that frames are captured to.\n> > >\n> > > For the Raspberry Pi platforms, it is possible for the Unicam driver\n> > > to drop frames without the knowledge of the pipeline handler, if for example\n> > > we do not recycle bayer buffers quick enough.\n> >\n> > So the driver doesn't increment the sequence number in that case ? Could\n> > this be fixed ?\n> \n> The driver increments sequence numbers based on frame interrupts, so they\n> change even if the frame is going to be dropped.\n\nDoes this mean that the pipeline handler could then detect that\ncondition, and react appropriately ?\n\n> > > Allowing the application\n> > > to look at sensor timestamps would allow it to detect these drops. Unless\n> > > I am mistaken, this would not be possible by failing the request, as the\n> > > sensor buffer recycling loop is asynchronous to the application request\n> > > loop. Having said that, they could be synchronised....\n> >\n> > This is also related to implementing true per-frame control,\n> > synchronizing the controls from the request with the buffers in which\n> > images are captured :-)\n> \n> As long as they are ISP based controls we are fine :-)\n\nThere's also manual exposure and analogue gain I'm afraid :-)\n\n> > > > > Kieran Bingham (8):\n> > > > > libcamera: controls: Add SensorSequence metadata control\n> > > > > libcamera: pipeline: Set the Sensor sequence number for all pipelines\n> > > > > cam: Use SensorTimestamp rather than buffer metadata\n> > > > > cam: Use Sensor sequence numbers and detect frame drop\n> > > > > qcam: main_window: Fix include ordering\n> > > > > qcam: Use Sensor sequence numbers and detect frame drop\n> > > > > gstreamer: gstlibcamerasrc: Fix include ordering\n> > > > > gstreamer: Use Sensor sequence numbers and detect frame drop\n> > > > >\n> > > > > src/cam/camera_session.cpp | 24 ++++++++--\n> > > > > src/cam/camera_session.h | 1 +\n> > > > > src/gstreamer/gstlibcamerasrc.cpp | 46 +++++++++++++++----\n> > > > > src/libcamera/control_ids.yaml | 8 ++++\n> > > > > src/libcamera/pipeline/ipu3/ipu3.cpp | 4 +-\n> > > > > .../pipeline/raspberrypi/raspberrypi.cpp | 3 ++\n> > > > > src/libcamera/pipeline/rkisp1/rkisp1.cpp | 4 +-\n> > > > > src/libcamera/pipeline/simple/simple.cpp | 12 +++--\n> > > > > src/libcamera/pipeline/uvcvideo/uvcvideo.cpp | 2 +\n> > > > > src/qcam/main_window.cpp | 28 +++++++++--\n> > > > > src/qcam/main_window.h | 1 +\n> > > > > 11 files changed, 111 insertions(+), 22 deletions(-)","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 D0B65BF415\n\tfor ;\n\tTue, 7 Dec 2021 16:47:57 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id 064C06086A;\n\tTue, 7 Dec 2021 17:47: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 937B260592\n\tfor ;\n\tTue, 7 Dec 2021 17:47:55 +0100 (CET)","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 05728556;\n\tTue, 7 Dec 2021 17:47:54 +0100 (CET)"],"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=\"qTgrDxdf\"; dkim-atps=neutral","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com;\n\ts=mail; t=1638895675;\n\tbh=r1qjQHqlqdpUn+vMjSmNKQaBr4m9lyQXemrlrcNlwPw=;\n\th=Date:From:To:Cc:Subject:References:In-Reply-To:From;\n\tb=qTgrDxdfbvnlVgiJrf+tIBJmJMCdgWCh5nI/hyLLMZSGrZo4LZO1aU7ipj3u7VhGi\n\t/rCQhpgkpW8f0r+qxLJ1pm81lW4lrGPN2BcJd226tBQ0YUfiW74M0p6pfxEWK83jcN\n\tVeXYmAYMo1ySyTFDiayzvhkf3zYzKbqPiPslEWLY=","Date":"Tue, 7 Dec 2021 18:47:26 +0200","From":"Laurent Pinchart ","To":"Naushir Patuck ","Message-ID":"","References":"<20211206233948.1351206-1-kieran.bingham@ideasonboard.com>\n\t\n\t\n\t\n\t","MIME-Version":"1.0","Content-Type":"text/plain; charset=utf-8","Content-Disposition":"inline","In-Reply-To":"","Subject":"Re: [libcamera-devel] [RFC PATCH 0/8] Request metadata:\n\tSensorSequence","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 ","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}},{"id":21660,"web_url":"https://patchwork.libcamera.org/comment/21660/","msgid":"","date":"2021-12-08T08:47:25","subject":"Re: [libcamera-devel] [RFC PATCH 0/8] Request metadata:\n\tSensorSequence","submitter":{"id":34,"url":"https://patchwork.libcamera.org/api/people/34/","name":"Naushir Patuck","email":"naush@raspberrypi.com"},"content":"Hi Laurent,\n\n\nOn Tue, 7 Dec 2021 at 16:47, Laurent Pinchart <\nlaurent.pinchart@ideasonboard.com> wrote:\n\n> Hi Naush,\n>\n> On Tue, Dec 07, 2021 at 03:15:23PM +0000, Naushir Patuck wrote:\n> > On Tue, 7 Dec 2021 at 14:22, Laurent Pinchart wrote:\n> > > On Tue, Dec 07, 2021 at 08:42:36AM +0000, Naushir Patuck wrote:\n> > > > On Tue, 7 Dec 2021 at 00:07, Laurent Pinchart wrote:\n> > > > > On Mon, Dec 06, 2021 at 11:39:40PM +0000, Kieran Bingham wrote:\n> > > > > > When completing a request, the individual stream buffers contain\n> a\n> > > > > > sequence number. This number is generated by the device that\n> ultimately\n> > > > > > fills that stream, but it might not be the sensor. Processing\n> through an\n> > > > > > ISP could cause the sequence numbers and timestamp data\n> associated with\n> > > > > > the completed buffer to be values representative of the ISP\n> processing\n> > > > > > rather than the (intended) capture device.\n> > > > > >\n> > > > > > Provide a new metadata control, still to be fully sketched out\n> which\n> > > > > > gives us a defined value to report the Camera sequence number.\n> This\n> > > > > > allows pipeline handlers to correctly set the value according to\n> the\n> > > > > > device that represents the capture from the sensor.\n> > > > > >\n> > > > > > This plumbing then allows applications to detect frame drops,\n> which were\n> > > > > > otherwise going unnoticed, and as such some basic additions have\n> been\n> > > > > > made to cam, qcam, and gstreamer to support this new data.\n> > > > > >\n> > > > > > Still possible:\n> > > > > > - Adding a validation to lc-compliance to make sure pipelines\n> set the\n> > > > > > SensorSequence on every frame.\n> > > > > >\n> > > > > > - Probably expecting some better gstreamer event integration\n> perhaps?\n> > > > > >\n> > > > > > - qcam should report more statistics on the processing overall\n> > > > > >\n> > > > > > - libcamera Tracepoints could be added as an event to track when\n> > > > > > frames are detected as dropped by the core framework.\n> > > > > >\n> > > > > > Anything else?\n> > > > >\n> > > > > A basic design question: when a frame is dropped, shouldn't we\n> report\n> > > > > the corresponding request as failed ? That's how the Android\n> camera HAL\n> > > > > API operates, and while that by itself isn't a good enough reason\n> to do\n> > > > > that same, I think it offers a better way to ensure that controls\n> get\n> > > > > synchronized with the buffers that frames are captured to.\n> > > >\n> > > > For the Raspberry Pi platforms, it is possible for the Unicam driver\n> > > > to drop frames without the knowledge of the pipeline handler, if for\n> example\n> > > > we do not recycle bayer buffers quick enough.\n> > >\n> > > So the driver doesn't increment the sequence number in that case ?\n> Could\n> > > this be fixed ?\n> >\n> > The driver increments sequence numbers based on frame interrupts, so they\n> > change even if the frame is going to be dropped.\n>\n> Does this mean that the pipeline handler could then detect that\n> condition, and react appropriately ?\n>\n\nYes it could. And this was discussed with Kieran before this change was\nmade.\nI think we concluded, that this may be logic that is common to all pipeline\nhandlers\nso might want to live in common code space rather than individual pipeline\nhandlers.\n\nThanks,\nNaush\n\n\n>\n> > > > Allowing the application\n> > > > to look at sensor timestamps would allow it to detect these drops.\n> Unless\n> > > > I am mistaken, this would not be possible by failing the request, as\n> the\n> > > > sensor buffer recycling loop is asynchronous to the application\n> request\n> > > > loop. Having said that, they could be synchronised....\n> > >\n> > > This is also related to implementing true per-frame control,\n> > > synchronizing the controls from the request with the buffers in which\n> > > images are captured :-)\n> >\n> > As long as they are ISP based controls we are fine :-)\n>\n> There's also manual exposure and analogue gain I'm afraid :-)\n>\n> > > > > > Kieran Bingham (8):\n> > > > > > libcamera: controls: Add SensorSequence metadata control\n> > > > > > libcamera: pipeline: Set the Sensor sequence number for all\n> pipelines\n> > > > > > cam: Use SensorTimestamp rather than buffer metadata\n> > > > > > cam: Use Sensor sequence numbers and detect frame drop\n> > > > > > qcam: main_window: Fix include ordering\n> > > > > > qcam: Use Sensor sequence numbers and detect frame drop\n> > > > > > gstreamer: gstlibcamerasrc: Fix include ordering\n> > > > > > gstreamer: Use Sensor sequence numbers and detect frame drop\n> > > > > >\n> > > > > > src/cam/camera_session.cpp | 24 ++++++++--\n> > > > > > src/cam/camera_session.h | 1 +\n> > > > > > src/gstreamer/gstlibcamerasrc.cpp | 46\n> +++++++++++++++----\n> > > > > > src/libcamera/control_ids.yaml | 8 ++++\n> > > > > > src/libcamera/pipeline/ipu3/ipu3.cpp | 4 +-\n> > > > > > .../pipeline/raspberrypi/raspberrypi.cpp | 3 ++\n> > > > > > src/libcamera/pipeline/rkisp1/rkisp1.cpp | 4 +-\n> > > > > > src/libcamera/pipeline/simple/simple.cpp | 12 +++--\n> > > > > > src/libcamera/pipeline/uvcvideo/uvcvideo.cpp | 2 +\n> > > > > > src/qcam/main_window.cpp | 28 +++++++++--\n> > > > > > src/qcam/main_window.h | 1 +\n> > > > > > 11 files changed, 111 insertions(+), 22 deletions(-)\n>\n> --\n> Regards,\n>\n> Laurent Pinchart\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 0766EBDB13\n\tfor ;\n\tWed, 8 Dec 2021 08:47:45 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id 3EFE260868;\n\tWed, 8 Dec 2021 09:47:44 +0100 (CET)","from mail-lf1-x129.google.com (mail-lf1-x129.google.com\n\t[IPv6:2a00:1450:4864:20::129])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id 1451060225\n\tfor ;\n\tWed, 8 Dec 2021 09:47:42 +0100 (CET)","by mail-lf1-x129.google.com with SMTP id c32so4170705lfv.4\n\tfor ;\n\tWed, 08 Dec 2021 00:47:42 -0800 (PST)"],"Authentication-Results":"lancelot.ideasonboard.com;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=raspberrypi.com header.i=@raspberrypi.com\n\theader.b=\"DCwV2yd1\"; dkim-atps=neutral","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=raspberrypi.com; s=google;\n\th=mime-version:references:in-reply-to:from:date:message-id:subject:to\n\t:cc; bh=/Nmnhu9LEFUpj14O7sc8qIJq4qO4sffSyi+3rdW0LUM=;\n\tb=DCwV2yd1zWbOdI0ISz4iJVzuIWTR+E3U/czX3qj2K/SfiFwE2DcmBkB6+GP6hP6QJR\n\tP2VY25R9KFFQPzdFeT2mSrOEWgpy28RaRPKX7qhgCt7si/EFzWWFe3Gh2XRC9qWV/1rE\n\ts5S2eVjktgkBmRDBmUaGicN7jxXwbpE0ZsU74mcqxjYPyzkPtAa0CjdVOqub5dZkiPUS\n\ts2GMuy6InK3dORYDK7arFkCvfcMLlo1syKHgpDQG/wZ1+Yba0K3THLDqNPvaLMi15Y+9\n\tAtu0SSXqlbItWG39C2EFVmQ9g1yys4B2epXLR0R54CReXRQO5jYGlsP+lwg41iDGIe+5\n\twZWQ==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20210112;\n\th=x-gm-message-state:mime-version:references:in-reply-to:from:date\n\t:message-id:subject:to:cc;\n\tbh=/Nmnhu9LEFUpj14O7sc8qIJq4qO4sffSyi+3rdW0LUM=;\n\tb=q2f0BTNa+nCXx7SqWZ2+17OZWVqOTRadvt6MNl+u8Bvk6q5vjuM0xC6eMpcNJUdSe4\n\taqzv6do6TyGlFCCiLRyxrC6s+7CCbHTlSoHaL/PteHOdZpNIT9rT8LTeaVOY6a3Dd+BM\n\tHVRooInLBUycU9wB5bkQ0/ghzJQaf8pT6KSrx83TwEQM5mcLg0tK0UL87KdsbIBzkZUn\n\t9T1WT5ls/UTrf3WE3xptEA4u+NkgF9wFH3SB4sC9K38Rkb4OjB/chmjSuplz5pkc+msq\n\tPHhbfNuW35nmUR4hiqGHhGMEIWzuaMMIxH5jU0HrMS5TB42V22tqbSgrqfpCFKOlIc26\n\twhUQ==","X-Gm-Message-State":"AOAM531RRRFLGvkcov+lkzUc/S95aIU8I7d7bNOTE3Sy9Ykq5yd0j4IT\n\tFDnQip6INYlgJHIr8yAd75/gK5dg1eI3E1JKJ6kWO7J86FazAw==","X-Google-Smtp-Source":"ABdhPJwmXoWG8O2SEAcni3niEhSml7CuquoxlT50bK0vXEo282tMO23IBahkNop39Idl8uYRGRFgvWM42Zdkbc9HKmM=","X-Received":"by 2002:a05:6512:39c4:: with SMTP id\n\tk4mr47230676lfu.79.1638953261185; \n\tWed, 08 Dec 2021 00:47:41 -0800 (PST)","MIME-Version":"1.0","References":"<20211206233948.1351206-1-kieran.bingham@ideasonboard.com>\n\t\n\t\n\t\n\t\n\t","In-Reply-To":"","From":"Naushir Patuck ","Date":"Wed, 8 Dec 2021 08:47:25 +0000","Message-ID":"","To":"Laurent Pinchart ","Content-Type":"multipart/alternative; boundary=\"000000000000efcf5705d29e8a74\"","Subject":"Re: [libcamera-devel] [RFC PATCH 0/8] Request metadata:\n\tSensorSequence","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 ","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}}]