gst: support sparse aravissrc streams

[0xa1da34ef]

Add sparse stream handling for aravissrc

This adds explicit timing and timeout policy controls so aravissrc can wait for sparse or triggered image streams without treating every empty buffer pop as a fatal error.

For triggered cameras, it is valid that no frame is available for some time. In that case the stream can still be healthy, so this change allows aravissrc to keep waiting when requested.

The existing fixed-rate behavior stays the default. Sparse timing skips fixed framerate caps and latency reporting, and GstBaseSrc unlock can interrupt waits cleanly.

Tested:

• Built from source and tested on Debian 12.
• Verified aravissrc through GStreamer with a Basler a2A1920-51gcBAS camera in triggered/sparse acquisition mode.

[EmmanuelP]

Hi,

Thanks for the patch. Could you provide some gstreamer pipeline examples that exhibit the problems this work fixes ? It'll help me review the changes.

Thanks.

[0xa1da34ef]

Hi,

Sure. The intention of these changes is to better support triggered and other sparse acquisition modes where long periods without frames are expected.

timeout-policy Controls how buffer acquisition timeouts are handled:

• error (default): timeout is reported as a stream error.
• wait: timeout is treated as normal and the source continues waiting for the next frame.

timing-mode Controls how the source advertises timing characteristics to GStreamer:

• fixed (default): regular continuous stream with a nominal frame rate.
• sparse: irregular/event-driven stream where long gaps between frames are expected.

The two properties address different aspects of sparse acquisition. timeout-policy controls error handling, while timing-mode describes the stream semantics to GStreamer. A triggered camera may produce frames irregularly and therefore be a sparse stream regardless of whether trigger timeouts should be considered an error. This is why the properties are independent and can be combined as needed.

timeout-policy	timing-mode
error	fixed	Continuous stream, timeouts are errors (default behaviour).
error	sparse	Irregular stream, but acquisition timeouts are still considered errors.
wait	fixed	Continuous stream where temporary frame gaps are tolerated.
wait	sparse	Irregular/event-driven stream where long gaps are expected and tolerated.

The default configuration remains unchanged (timeout-policy=error, timing-mode=fixed).

The primary motivation is triggered acquisition. With the default behaviour (error + fixed), a pipeline may fail if triggers stop arriving for longer than the acquisition timeout:

gst-launch-1.0 aravissrc features="TriggerSelector=FrameStart TriggerMode=On TriggerActivation=RisingEdge TriggerSource=Line1" timeout-policy=error timing-mode=fixed ! video/x-raw,format=RGB,width=720,height=540 ! videoconvert ! autovideosink

For sparse triggered acquisition, the pipeline can instead remain running while waiting for the next trigger:

gst-launch-1.0 aravissrc features="TriggerSelector=FrameStart TriggerMode=On TriggerActivation=RisingEdge TriggerSource=Line1" timeout-policy=wait timing-mode=sparse ! video/x-raw,format=RGB,width=720,height=540 ! videoconvert ! autovideosink

[EmmanuelP]

Ok. Thanks for the explanation and the example pipelines. I will have a look soon.