| Message ID | 20260805151819.16382-1-ballen4705@googlemail.com |
|---|---|
| Headers | show |
| Series |
|
| Related | show |
Hi Bruce, Quoting Bruce Allen (2026-08-05 16:18:17) > Hi Barnabás, > > Thank you for the review, v3 follows. These are documentation-only > changes in response to your comments: This shows up in my email in a single thread with v1, and v2, which is already marked as 'superceded' between v1 and v2 so wouldn't be likely to get my review (except that luckily I noticed it pop up this time). Please send new series in a new separate thread. There's no need to use 'git-send-email --in-reply-to' or such, just a fresh send with the new version. But don't resend this now ... I spotted this one this time :-) -- Regards Kieran > - Request metadata is a subheading under Handle request completion events, > just before Request queueing. > > - Metadata is described via ControlId::direction() / Direction::Out, not YAML. > > - Dropped the explicit <int64_t> template argument from the > ControlList::get() example. I did NOT remove the > static_cast<int64_t> calls in the pipeline code; if that is what you > intended, I will do so in a follow-up. [Note that > FrameMetadata::sequence is unsigned int whereas > FrameMetadata::timestamp is already uint64_t.] > > - SensorSequence details moved into the SensorSequence control docs. > > - Documented stop/start: sequence restarts from 0 each session. > > - Documented presence: when SensorTimestamp is set on a successful frame, > SensorSequence is also set. > > > My opinion regarding fail-on-drop vs SensorSequence: > > I prefer not to fail requests on drops. That would break existing apps > and force one policy on everyone. Drops matter in some use cases and > not others. SensorSequence lets the application decide. > > Cheers, > Bruce > > -- > 2.55.0
Hi Kieran, Thanks, and apologies, I don't do this very often. I'll try to get it right the next time. Also, I messed up the second link in my reply to Barnabás (CCd to Naushir) a minute ago. It should have been: https://github.com/libcamera-org/libcamera/blob/master/src/libcamera/v4l2_videodevice.cpp PS: just for fun, attaching a two week drop histogram, 13.7 drops per day, in all 177 drops from about 82 million frames. Cheers, Bruce On 05.08.26 17:40, Kieran Bingham wrote: > Hi Bruce, > > Quoting Bruce Allen (2026-08-05 16:18:17) >> Hi Barnabás, >> >> Thank you for the review, v3 follows. These are documentation-only >> changes in response to your comments: > > This shows up in my email in a single thread with v1, and v2, which is > already marked as 'superceded' between v1 and v2 so wouldn't be likely > to get my review (except that luckily I noticed it pop up this time). > > Please send new series in a new separate thread. There's no need to use > 'git-send-email --in-reply-to' or such, just a fresh send with the new > version. But don't resend this now ... I spotted this one this time :-) > > -- > Regards > > Kieran > >> - Request metadata is a subheading under Handle request completion events, >> just before Request queueing. >> >> - Metadata is described via ControlId::direction() / Direction::Out, not YAML. >> >> - Dropped the explicit <int64_t> template argument from the >> ControlList::get() example. I did NOT remove the >> static_cast<int64_t> calls in the pipeline code; if that is what you >> intended, I will do so in a follow-up. [Note that >> FrameMetadata::sequence is unsigned int whereas >> FrameMetadata::timestamp is already uint64_t.] >> >> - SensorSequence details moved into the SensorSequence control docs. >> >> - Documented stop/start: sequence restarts from 0 each session. >> >> - Documented presence: when SensorTimestamp is set on a successful frame, >> SensorSequence is also set. >> >> >> My opinion regarding fail-on-drop vs SensorSequence: >> >> I prefer not to fail requests on drops. That would break existing apps >> and force one policy on everyone. Drops matter in some use cases and >> not others. SensorSequence lets the application decide. >> >> Cheers, >> Bruce >> >> -- >> 2.55.0
Hi Barnabás, Thank you for the review, v3 follows. These are documentation-only changes in response to your comments: - Request metadata is a subheading under Handle request completion events, just before Request queueing. - Metadata is described via ControlId::direction() / Direction::Out, not YAML. - Dropped the explicit <int64_t> template argument from the ControlList::get() example. I did NOT remove the static_cast<int64_t> calls in the pipeline code; if that is what you intended, I will do so in a follow-up. [Note that FrameMetadata::sequence is unsigned int whereas FrameMetadata::timestamp is already uint64_t.] - SensorSequence details moved into the SensorSequence control docs. - Documented stop/start: sequence restarts from 0 each session. - Documented presence: when SensorTimestamp is set on a successful frame, SensorSequence is also set. My opinion regarding fail-on-drop vs SensorSequence: I prefer not to fail requests on drops. That would break existing apps and force one policy on everyone. Drops matter in some use cases and not others. SensorSequence lets the application decide. Cheers, Bruce