-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Runs only as fast as slowest cam #1
Comments
You are absolutely right! To solve it, you have to follow another strategy. The problem is that every application requires a different solution; there is no 'one' genetic outcome. For instance, you can give each thread its own processing algorithm, leaving the main thread almost empty. There you concentrate on the image stitching. Or you can signal the main thread when it requests a frame, that is now not ready yet, and it should revisit this thread later again. The how idea of this repo is a simple starting point for a multithreading camera app. |
@Benebaby @Qengineering Handling multithreading for cameras at different sampling rates and resolutions presents an exciting engineering challenge. I am eager to spend a few hours at my weekends prototyping these features. It would be fantastic if you could create a branch with an initial approach, and I would be happy to test and contribute to it. Alternatively, a new issue can be raised. For instance, let me share the features of these two cameras (External USB Logitech Webcam C930e and embedded webcam HD Camera: HD Camera) as something to be used to prototype something useful. Thanks, Miguel See logs for `v4l2-ctl -d /dev/video* --list-formats-ext`
|
@mxochicale, thanks for your enthusiasm! |
@Qengineering Agreeing with the goal of having a general-purpose solution rather than a specific one will continuously add significant value to the users of your repository! For the specific requirement of multiple cameras running at different frame rates, I think a simple example with two cameras would be extremely useful. Once sorted out, it could be scaled to support four or more cameras. For example, I am thinking on the use case with two cameras at different resolutions and different fps with arguments or some kind of configuration file to setup the app. In terms of these two cameras, it could be the case of camera A with 640x480 image resolution, running at 30.000 fps and Camera B with 1920x1080 image resolution, running at 5.000 fps. Similarly, perhaps this would be a good start to think and brainstorm frame lag quantification and synchronisation techniques for threads. What do you think? Perhaps, you would like to create a discussion forum to move such discussion there or create a new issue to not spam @Benebaby and yourself here! Thanks, Miguel |
@mxochicale, Feel free to fork the repo for add-ons, and extensions. I do not have the time to manage such a project, busy as I am with other (commercial) projects. Good to know, YoloIP and Xactai parking have already incorporated the features you mentioned above! |
The main loop where all images get stiched together and get previewed runs only as fast as the slowest camera. So if one camera runs on a slow framerate it effects the other cameras wich should not happen.
The text was updated successfully, but these errors were encountered: