On Thu, 05 Jun 2025 00:49:28 -0400, c186282 <
[email protected]> wrote:
"Motion" seems to fix this ... but it's a BIG program and
trying to look through the source hasn't been a big help.
Cam, just 1-fps, try to read/record/display with OpenCV.
No, RTSP streaming is bad - WAY too much latency. Not
entirely sure how RTSP 'fixes' stuff either. However
usually being part of the cam firmware it can maybe
wait for the proper start bytes, read the stream in
real time ?
Faster than 1-fps ... wow ... what processing overhead !
The prob is exact TIMING ... the cam and my boxes trying
to read the JPG are often a bit out of sync. This leads
to partial/blended/UGLY images maybe 20% of the time.
JPGs have clear start/end byte sequences. In theory
you can read them byte by byte, looking for those.
Not hard.
But what if the jpg CHANGES right during when you
are reading it from the cam ?
See
https://www.raspberrypi.com/documentation/accessories/camera.html about the rolling/global shutter differences.
The simplest 'fix' is to just REJECT improper JPGs,
stick to the last-good and wait for the next-good.
This MAY be what Motion does. It prevents 'ugly'
images. Alas if your box is particularly out of
sync with the cam you may miss a lot of updates.
Live 'ugly' images can sometimes be better than
NO new images.
In any case, if anyone here has delved deeper into
this subject, please offer some suggestions. The
dependency is on external devices, they do what
they do.
The biggest bottleneck is likely going to be how the camera is connected to the computer.
With usb, at 640x480, between 9 and 10 fps.
At 1280x720, 2.5 to 4 fps.
at 1920x1080, 0.5 to 3 fps.
The framerate varies depending on the light level. Less light, less detail, higher frame rate.
My "security camera" is a simple usb camera sitting in the window beside my front door.
It's connected to an rpi5 sitting on a nearby table. As it's looking through glass, infrared
can not be used. It's a cheap camera meant to be used as a webcam.
I have an rpi4 connected to a montior beside my main computer. I use that rpi4 to ssh
(with X forwarding) to the rpi5, and run guvcview on the rpi5 to view the video using mjpg
at 1920x1080. Currently (daylight, cloudy with light rain) guvcview is showing 1.99 fps.
That way I can see anyone approaching my front door, from my desk. I don't bother recording
or running motion, though I've experimented with both in the past.
If you want reletively cheap camcorder quality, use an rpi 5 with a global shutter camera
recording onto it's pcie nvme drive.
If you want to use motion, set up a script that stops guvcview, renames it's video capture
file to include the date/time in the file name, restarts guvcview, and then runs motion on
the captured video.
I'm not an expert on video. Just sharing what I've learned through trial and error.
Regards, Dave Hodgins
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)