[Proposal]: Change PiGear to have a blocking `read()` function

[rolson24]

Issue guidelines

• [X] I've read the Issue Guidelines and wholeheartedly agree.

Issue Checklist

• [X] I have searched open or closed issues and found nothing related to my idea.
• [X] I have read the Documentation and it doesn't mention anything about my idea.
• [X] To my best knowledge, my idea wouldn't break something for other users.

Describe your Idea

Right now the PiGear read function has a docstring that says: "Extracts frames synchronously from monitored deque, while maintaining a fixed-length frame buffer in the memory, and blocks the thread if the deque is full." But when I look at the PiGear class it appears that the deque it refers to is internal to PiCamera. The PiCamera deque does correctly queue the frames, however the read() function in PiGear will simply return the current frame at the end of the queue without clearing it. This means that if you call the read() function faster than the camera is sending frames, it will just return the same frame several times until a new frame is sent from the camera. This is an issue if you are using FFMPEG to encode a video and you have set the input frame rate to be the same as the camera framerate because if the read() function is called faster than the camera framerate, you will send duplicate frames to the WriteGear, which will then interpret them as unique frames which will mess up the final video file's time stamps and framerate. My solution would be to implement the same queue functionality from the CamGear class which correctly does not return the same video frame over and over when read() is called.

Use Cases

The main use case for this is people who are using the PiGear module to capture frames from a Raspberry Pi camera and then using the WriteGear module to encode those frames into a video in a while loop. This would ensure that the WriteGear module would be able to use the camera's framerate as its input framerate without having to worry about if their while loop is running too fast.

Any other Relevant Information?

I would be willing to submit a PR if this is something that you think is needed.

[welcome[bot]]

Thanks for opening this issue, a maintainer will get back to you shortly!

In the meantime:

• Read our Issue Guidelines, and update your issue accordingly. Please note that your issue will be fixed much faster if you spend about half an hour preparing it, including the exact reproduction steps and a demo.
• Go comprehensively through our dedicated FAQ & Troubleshooting section.
• For any quick questions and typos, please refrain from opening an issue, as you can reach us on Gitter community channel.

[rolson24]

I played around with the code more and I now understand why you wrote it this way. If you use a queue to only send the frame once it breaks the pipeline which makes the encoder way slower. I instead used "-re" as an arguement to the FFMPEG command with the "-ffpreheaders" param in the WriteGear object, which limits FFMPEG to encode at the input framerate only. Great job on this library! Would love to contribute if you ever need any help.