How to shut down when in acquisition? Usually blocking operations (arv_stream_pop_buffer) takes an Event/conditional that can be signalled to abort/unblock safely This is particularly important when used with camera in some hardware triggered mode, the next image might be hours away. But we might want to stop acquisition and shut down the application. Or will an operation on the stream unblock the pop_buffer safely ? If so, which one?
arv_buffer allows custom buffers (which is good), but doesn’t allow to change them. Typically your vision SDK’s image class is wired up to the camera interface descriptor (arv_buffer using custom memory constructor) and queued for acquisition. Then afterwards, the image reference is removed from the descriptor and dispatched in the image processing pipeline and the descriptor is wired to a new image and put back in the queue. A method/setter to do that (wire up a new pointer to an image buffer with an exisiting arv_buffer) is missing. Sure, we can destroy/recreate the arv_buffer as a workaround, but that is not as elegant.
Poll the incoming buffers using arv_stream_try_pop_buffer() or arv_stream_timeout_pop_buffer()
Or register a callback in the arv_camera_create_stream() call. When the callback is awaken with type==ARV_STREAM_CALLBACK_TYPE_BUFFER_DONE, a buffer is necessarily available in the queue. Beware the callback is called from the stream receiving thread, you can not access to the camera from there (only the buffer queue), and the time spend handling the buffer in this callback is also less time spent handling the incoming packets.
Or use the stream new-buffer signal. The signal handler will also be called from the stream receiving thread.
That could be an interresting addition to the ArvBuffer API. Patch welcome !
That seems the best option for me, with a 500ms timeout or so, where we can poll if we need to shutdown. This one doesn’t block the stream thread? We sometimes do an additional image rotate in the thread we use per camera, iow that runs the multi example skeleton.
Oh dear. A WAAAYP as reaction . (We Are Anxiously Awaiting Your Patches). I’ll see what I can do, arvbuffer looks simple enough, but I’ll have to setup a msys build environment first, which isn’t my cup of tea as a Delphi/Free Pascal developer.
. (We Are Anxiously Awaiting Your Patches). I’ll see what I can do, arvbuffer looks simple enough, but I’ll have to setup a msys build environment first, which isn’t my cup of tea as a Delphi/Free Pascal developer.