| Message ID | 20260626003712.26624-1-ballen4705@googlemail.com |
|---|---|
| Headers | show |
| Series |
|
| Related | show |
Hi Bruce, Quoting Bruce Allen (2026-06-26 01:37:10) > Hi, > > This tiny patch series adds a Raspberry Pi vendor metadata control > SensorSequence that exposes the Unicam frontend > FrameBuffer::metadata().sequence on completed requests (VC4 pipeline). This is interesting work, and feels familiar because I looked at similar things in the past: Request metadata: SensorSequence - https://patchwork.libcamera.org/project/libcamera/list/?series=2822 Sequence Observer - https://patchwork.libcamera.org/project/libcamera/list/?series=3083 I can't recall, but it felt/seemed like these patches didn't gain traction. Perhaps your requirements could help drive an update. > Motivation: applications diagnosing frame loss need a counter tied to > frontend capture, not just delivered-frame or control-list > timing. Gaps in this sequence indicate frames that did not reach the > frontend stream before the previous request completed. I agree - I think that can be valuable information. > The control is defined in control_ids_rpi.yaml, set in vc4.cpp at > Unicam dequeue, and propagated in pipeline_base.cpp like > SensorTimestamp and FrameWallClock. Python bindings follow from > existing pycamera codegen. Anything like this should apply to all platforms. There's nothing RPi specific about a sensor sequence number. -- Kieran > > Tested: builds on master @ 29eb112 with -Dpipelines=rpi/vc4 > -Dipas=rpi/vc4 -Dpycamera=enabled; verified > libcamera.controls.rpi.SensorSequence imports from the staged > tree. Tested on Raspberry Pi CM4, correctly detects dropped frames. > > Cheers, > Bruce Allen
Hi Kieran, thanks for picking up on this so quickly! >> This tiny patch series adds a Raspberry Pi vendor metadata control >> SensorSequence that exposes the Unicam frontend >> FrameBuffer::metadata().sequence on completed requests (VC4 pipeline). > This is interesting work, and feels familiar because I looked at similar > things in the past: > > Request metadata: SensorSequence > - https://patchwork.libcamera.org/project/libcamera/list/?series=2822 > > Sequence Observer > - https://patchwork.libcamera.org/project/libcamera/list/?series=3083 I saw those, and was surprised that they had not been taken up. > I can't recall, but it felt/seemed like these patches didn't gain > traction. Perhaps your requirements could help drive an update. Tracking sensor drops is interesting: on my system there is a periodic pattern of drops that I don't understand (yet). So IMO exposing this information will be helpful to others. And it's such low cost (a few lines of code, tens of nanoseconds of ops, a few bytes of memory) that I can't see any reason NOT to. >> Motivation: applications diagnosing frame loss need a counter tied to >> frontend capture, not just delivered-frame or control-list >> timing. Gaps in this sequence indicate frames that did not reach the >> frontend stream before the previous request completed. > I agree - I think that can be valuable information. (:-) You (we) are "preaching to the converted". >> The control is defined in control_ids_rpi.yaml, set in vc4.cpp at >> Unicam dequeue, and propagated in pipeline_base.cpp like >> SensorTimestamp and FrameWallClock. Python bindings follow from >> existing pycamera codegen. > Anything like this should apply to all platforms. There's nothing RPi > specific about a sensor sequence number. I'd be happy with a more general solution, but I'm not set up to test this more broadly than my RPI project. Cheers, Bruce
Hi Kieran, based on your feedback, I've posted v2 of this patch, which makes SensorSequence a standard metadata control across all pipeline handlers that provide SensorTimestamp. For the record, v2 is here: https://lists.libcamera.org/pipermail/libcamera-devel/2026-July/059979.html Cheers, Bruce