mirror of
https://github.com/gen2brain/cam2ip.git
synced 2026-04-26 22:55:53 +03:00
[GH-ISSUE #21] Only open camera when capturing #21
Labels
No labels
enhancement
enhancement
pull-request
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/cam2ip#21
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @orulz on GitHub (May 15, 2020).
Original GitHub issue: https://github.com/gen2brain/cam2ip/issues/21
This is a fantastic tool! It would work better for my case if it if it did not grab the camera as soon as the server is started, but instead only when it is actively serving video or images. This might result in some lag time when starting up, but this would not be a problem for me. Leaving the camera off when the server is not in use would be helpful.
Not familiar with go or opencv, but it looks that the camera is initialized in New()
github.com/gen2brain/cam2ip@19ea541157/camera/camera_cv2.go (L26)Not sure but maybe that initialization could be deferred? Possibly to Read() ?? Or maybe done by the handlers? (JPEG would release immediately; MJPEG or HTTP would release when the connection is closed)
@gen2brain commented on GitHub (May 15, 2020):
It seems like a nice addition. This should be done by handlers, not Read(), and if option enabled main should not initialize the camera. I think it should not be a big job but need to check first, not sure when. What do you think option should be called,
lazysounds ok?@orulz commented on GitHub (May 15, 2020):
"Deferred camera initialization" is the most descriptive way, but that doesn't fit well into a short CLI option, so "lazy" works. Kind of fun.
@orulz commented on GitHub (May 15, 2020):
One thing to think about is, what happens when multiple clients are accessing the camera at once.
Would need to maintain a client counter and only release the camera when the client counter reaches zero.
@gen2brain commented on GitHub (May 15, 2020):
Every handler will anyway check if camera is nil/null on every request and will initialize it if it is not, so one client closes tab/connection and it closes the camera, the other client on the next request will again initialize the camera. Needs to be tested but I would not want to complicate this much.
@orulz commented on GitHub (May 15, 2020):
If somebody is viewing MJPEG stream they would not want to have the camera turned off underneath them by somebody capturing a single JPEG... This would result in a glitch in the video stream as the camera has to be reinitialized for the next MJPEG frame. I guess that's not the end of the world, but not perfect. Or is that not an issue for some other reason I'm not seeing? Oh well! It's your project, your call!
Thanks again for this project and thanks for being so responsive!
@orulz commented on GitHub (May 15, 2020):
Maybe initialize as you suggest, and handle closing the camera by a ConnState hook ( https://golang.org/pkg/net/http/#ConnState ) that increments a counter on StateNew, decrements on StateClosed (maybe StateHijacked too) and closes the camera whenever the counter transitions to zero.
Again not a Go expert, just reading the docs...
@gen2brain commented on GitHub (May 15, 2020):
There is already notification for close here https://github.com/gen2brain/cam2ip/blob/master/handlers/mjpeg.go#L41 and for HTML on socket close can close the camera. My point is that if there is a need for e.g. many mjpeg clients, one can put some mjpeg-proxy in front of cam2ip, there are many of them, if lazy option doesn't work for many clients, user can disable it etc.
Just trying to not further complicate the code, for now everything is clear and simple, but I will consider also your hint when I start to work on this.