Fine for triggering the captures, but can I suggest you read up on semaphores as the correct way to signal back and forth.
The other thing you could do is have a MMAL_QUEUE_T between the threads.
In callback(), if the flag is set then mmal_queue_put(queue, buffer) and do NOT return it to the rawcam component with mmal_port_send_buffer. In your other thread, wait with mmal_queue_wait(queue). Once the buffer is delivered your thread will be unblocked and you'll get the buffer. Do whatever processing/network sending/whatever on it, and then return it yourself to the component with mmal_port_send_buffer. It saves memcpying data around the place as you're doing.
Do check that output->buffer_num is large >=6 so that you still have double buffering available on the component itself and won't stall it.
A slight nasty in that you don't check that the buffer->length of the buffer that triggers the malloc is the same as the length of subsequent buffers.fooforever wrote:But when I get images out the other end they look something like this:
I seem to be getting either a repeated top bit of the frame at the bottom or the top of the next frame. Any idea what's going wrong? Obviously this doesn't happen with the saved images, but as far as I'm aware im kinda handling everything in the same way.
Without knowing how your processing is detecting the start of frames it's difficult to say.
From previous posts you're using the OV5467 V1 camera module. Your webp (why?!) file appears to be 1293x974, so a slight munge on 1296x972? Are you sure you're running mode 4 and not mode 5? The buffers are likely to be adjacent in memory, so copying too far would result in reading off the end of one into the start of the next. What length are the buffers being reported as?