I have read through the source of rpicam-vid (among other things), and sort of understand what's going on.
In the event loop, there is some setup going on to configure the camera settings, encoder and output objects.
The loop runs as:
wait for a message from the camera stack (check for quit, and timeouts)
get a completed request
run the encoder
show the preview window
Now, I assume that the encoder will call the OutputReady and MetadataReady callbacks appropriately.
So far so good, I am happy with this.
However, in another thread I am running http server code to accept GET /stream.mjpeg requests. This creates another thread to service the request.
And this is where I start to run into issues. If I have no HTTP clients, I can "ignore" the stream (effectively discarding each frame).
If I have a client, I want it to know that a frame is ready, and to be able to send that frame to it.
My initial thought is that I need a custom Output derived class, which has listeners, and that as a client comes on line, it adds itself to the listeners of that class, and when the connection drops, removes itself too. In the OutputReady of the derived class, I iterate through the listeners and provide them with the data to output (BUT not modify).
Does anyone see any glaringly obvious issues with this approach?
In the event loop, there is some setup going on to configure the camera settings, encoder and output objects.
The loop runs as:
wait for a message from the camera stack (check for quit, and timeouts)
get a completed request
run the encoder
show the preview window
Now, I assume that the encoder will call the OutputReady and MetadataReady callbacks appropriately.
So far so good, I am happy with this.
However, in another thread I am running http server code to accept GET /stream.mjpeg requests. This creates another thread to service the request.
And this is where I start to run into issues. If I have no HTTP clients, I can "ignore" the stream (effectively discarding each frame).
If I have a client, I want it to know that a frame is ready, and to be able to send that frame to it.
My initial thought is that I need a custom Output derived class, which has listeners, and that as a client comes on line, it adds itself to the listeners of that class, and when the connection drops, removes itself too. In the OutputReady of the derived class, I iterate through the listeners and provide them with the data to output (BUT not modify).
Does anyone see any glaringly obvious issues with this approach?
Statistics: Posted by SteveSpencer — Wed Aug 21, 2024 11:11 am — Replies 0 — Views 24