OK, I've been pounding at this for 10+ days now.

What's NEEDED is for a Pi4 to read either rtsp
streams from security cams OR the transient
JPGs said cameras offer - and then put it into
displayable video frames.

SOME of the cams will NOT do rtsp properly - you
can sometimes see them in VLC, but Motion and
such can't capture it properly.

However, with RTSP and OpenCV, the big BIG problem
is LATENCY. I'm seeing up to like 30+ seconds. Unless
you use a couple of 'back-ends', the commands to shrink
the BUFFERS don't work - and I've not got V4L2 backend
to work.

Basics - something reads the cams, either by rtsp
or by directly downloading those JPGs. Have been
using Motion - which is a great app - but it's
really meant for faster computers. It creates a
very handy MJPEG stream on a port that OpenCV can
easily read/crop/resize/display.

However - LATENCY - severe !!! It's the fuckin'
buffering and after massive searching I've yet
to find a good/general/sane fix. And no I'm
NOT gonna re-write half the OS or Motion to
find success.

Yesterday I wrote a threaded Py app that's a sort
of "engine" which uses curl - faster than wget -
to pull those JPGs out of the cams. Added "lock"
files for WHILE it's downloading. The display
app respects those locks. It all WORKS, almost
no latency, but there's another issue ...

The issue is that the JPGs are replaced every
second, or two or three times a second depending.
Curl, and wget, only download WHAT THEY FIND.

Sometimes that's a full, real, viable, JPG.
Sometimes it's a PARTIAL JPG ... either not
finished or partially overwritten by new data.
This inserts lots of "ugly" frames, even at
relatively low-FPS rates.

My "engine" simply downloads existing JPGs from
the cams and puts them in an identically-named
files. FFMPEG - at least on the current Deb derivs -
the "overwrite" option does NOT work ... it INSISTS
on serially-numbered output JPGs, which is a crappy,
CPU-sucking, "solution" to deal with.

Pi4s have FAIR cpu - but they ain't I9s.

All that OpenCV is doing is reading the disk files,
or attempting rtsp, and displaying the cams in up
to four placed/scaled frames onscreen (btw the
placement does NOT work with Wayland).

I'm attempting to free the Pis from using MJPEG
streams created BY the faster i9 server + motion
+ apache. Was just displaying a web page of one
to four live frames via Motion. HTML plus a
little WebKit resize stuff worked fine. But, it's
DEPENDENT on the much-stronger cpu doing all
this stuff and current circumstances may mean
that stronger CPU is gonna go away. SO,

I want the P4 display units to be "independent",
with "Motion" or whatever running ON them to grab
the security cams themselves. THEN we can display.

SO - the TWO enemies - "Latency" from any use of
"Motion", or "crappy frames" using Curl.

WORKAROUNDS :

Use Chromium and PHP-html/WebKit/iframes to directly
read/scale/show the JPGs from the cams. Browsers
a bit of a pain to deal with and the WebKit
per-iframe defs are VERY hard to work with, can
take half a day to get everything "just right".
Browsers work best with MJPEG streams like
"Motion" creates ... but LATENCY creeps in
big time.

So .......... noticed that if you bring in the
JPG using a browser it's like PERFECT and very
INSTANT. Seems they can detect a "complete" JPG
and download it MUCH faster than curl/wget.

So ....... how to reproduce that "instant/perfect"
effect NOT involving browsers ??? What can be
faster than curl for downloading a JPG from a
remote http device - either as a straight-up file
or some kind of MJPEG stream ??????????

Clearly FFox/Chromium CAN do this, so there's
SOME faster/better trick.

I've spend endless hours searching on this issue,
and found NOTHING that really improves ...

So, to encapsulate, VideoCapture(xxx) is not a
good solution for rtsp/mjpeg because of the
buffering problem. 'Motion' also has a serious
latency prob on a P4. Browser/html-php solutions
can work, but are a real pain in the ass to
deal with - no handy .config files for defining
sources/crops/scaling.

And that's MY "Project Of The Week".

I'm retiring very soon now ... but I'd LIKE to
get the security cam stuff for those who need to
see live feeds work properly/independently. Sort
of my "gift" to the regular-level workers and
a continuing legacy for PIs. The new guys can
learn to cope with Linux/PIs ... my "gift"
to those Winders-centrics. IF they screw it
up they WILL get ENDLESS grief - "WHERE ARE
MY CAMERA FEEDS ??? !!!" :-)

Too much ... well, better more detail than not
enough eh ? :-)

.. . .

Oh ...recent "Motion" on Deb/Pi4 ... you HAVE
to put the poorly-documented "start_motion_daemon=yes"
into "motion.conf" ... you can leave the other
'daemon on" undefined or off. DO use systemctl
to ENABLE the daemon. I modified the systemd
file in /usr/lib/systemd/system/motion.service
to include RESTARTING on failure. DO remember
to do "systemctl daemon-reload" after that.

The alt approach is to start Motion in root crontab,
but then you can't easily start/stop/restart. For
goodness I usually restart the Motion daemon at
least twice a day using root crontab.

On 11/11/2023 06:33, 56d.1152 wrote:
> OK, I've been pounding at this for 10+ days now.
>
> What's NEEDED is for a Pi4 to read either rtsp
> streams from security cams OR the transient
> JPGs said cameras offer - and then put it into
> displayable video frames.
>
> SOME of the cams will NOT do rtsp properly - you
> can sometimes see them in VLC, but Motion and
> such can't capture it properly.
>
> However, with RTSP and OpenCV, the big BIG problem
> is LATENCY. I'm seeing up to like 30+ seconds. Unless
> you use a couple of 'back-ends', the commands to shrink
> the BUFFERS don't work - and I've not got V4L2 backend
> to work.
>
> Basics - something reads the cams, either by rtsp
> or by directly downloading those JPGs. Have been
> using Motion - which is a great app - but it's
> really meant for faster computers. It creates a
> very handy MJPEG stream on a port that OpenCV can
> easily read/crop/resize/display.
>
> However - LATENCY - severe !!! It's the fuckin'
> buffering and after massive searching I've yet
> to find a good/general/sane fix. And no I'm
> NOT gonna re-write half the OS or Motion to
> find success.
>
> Yesterday I wrote a threaded Py app that's a sort
> of "engine" which uses curl - faster than wget -
> to pull those JPGs out of the cams. Added "lock"
> files for WHILE it's downloading. The display
> app respects those locks. It all WORKS, almost
> no latency, but there's another issue ...
>
> The issue is that the JPGs are replaced every
> second, or two or three times a second depending.
> Curl, and wget, only download WHAT THEY FIND.
>
> Sometimes that's a full, real, viable, JPG.
> Sometimes it's a PARTIAL JPG ... either not
> finished or partially overwritten by new data.
> This inserts lots of "ugly" frames, even at
> relatively low-FPS rates.
>
> My "engine" simply downloads existing JPGs from
> the cams and puts them in an identically-named
> files. FFMPEG - at least on the current Deb derivs -
> the "overwrite" option does NOT work ... it INSISTS
> on serially-numbered output JPGs, which is a crappy,
> CPU-sucking, "solution" to deal with.
>
> Pi4s have FAIR cpu - but they ain't I9s.
>
> All that OpenCV is doing is reading the disk files,
> or attempting rtsp, and displaying the cams in up
> to four placed/scaled frames onscreen (btw the
> placement does NOT work with Wayland).
>
> I'm attempting to free the Pis from using MJPEG
> streams created BY the faster i9 server + motion
> + apache. Was just displaying a web page of one
> to four live frames via Motion. HTML plus a
> little WebKit resize stuff worked fine. But, it's
> DEPENDENT on the much-stronger cpu doing all
> this stuff and current circumstances may mean
> that stronger CPU is gonna go away. SO,
>
> I want the P4 display units to be "independent",
> with "Motion" or whatever running ON them to grab
> the security cams themselves. THEN we can display.
>
> SO - the TWO enemies - "Latency" from any use of
> "Motion", or "crappy frames" using Curl.
>
> WORKAROUNDS :
>
> Use Chromium and PHP-html/WebKit/iframes to directly
> read/scale/show the JPGs from the cams. Browsers
> a bit of a pain to deal with and the WebKit
> per-iframe defs are VERY hard to work with, can
> take half a day to get everything "just right".
> Browsers work best with MJPEG streams like
> "Motion" creates ... but LATENCY creeps in
> big time.
>
> So .......... noticed that if you bring in the
> JPG using a browser it's like PERFECT and very
> INSTANT. Seems they can detect a "complete" JPG
> and download it MUCH faster than curl/wget.
>
> So ....... how to reproduce that "instant/perfect"
> effect NOT involving browsers ??? What can be
> faster than curl for downloading a JPG from a
> remote http device - either as a straight-up file
> or some kind of MJPEG stream ??????????
>
> Clearly FFox/Chromium CAN do this, so there's
> SOME faster/better trick.
>
> I've spend endless hours searching on this issue,
> and found NOTHING that really improves ...
>
> So, to encapsulate, VideoCapture(xxx) is not a
> good solution for rtsp/mjpeg because of the
> buffering problem. 'Motion' also has a serious
> latency prob on a P4. Browser/html-php solutions
> can work, but are a real pain in the ass to
> deal with - no handy .config files for defining
> sources/crops/scaling.
>
> And that's MY "Project Of The Week".
>
> I'm retiring very soon now ... but I'd LIKE to
> get the security cam stuff for those who need to
> see live feeds work properly/independently. Sort
> of my "gift" to the regular-level workers and
> a continuing legacy for PIs. The new guys can
> learn to cope with Linux/PIs ... my "gift"
> to those Winders-centrics. IF they screw it
> up they WILL get ENDLESS grief - "WHERE ARE
> MY CAMERA FEEDS ??? !!!" :-)
>
> Too much ... well, better more detail than not
> enough eh ? :-)
>
> . . .
>
> Oh ...recent "Motion" on Deb/Pi4 ... you HAVE
> to put the poorly-documented "start_motion_daemon=yes"
> into "motion.conf" ... you can leave the other
> 'daemon on" undefined or off. DO use systemctl
> to ENABLE the daemon. I modified the systemd
> file in /usr/lib/systemd/system/motion.service
> to include RESTARTING on failure. DO remember
> to do "systemctl daemon-reload" after that.
>
> The alt approach is to start Motion in root crontab,
> but then you can't easily start/stop/restart. For
> goodness I usually restart the Motion daemon at
> least twice a day using root crontab.
>

I've got a Raspberry Pi Model B Rev 2 with both a Pi camera and a USB
camera, Buster (10.13), lighttpd 1.4.53 and Motion 4.1.1 saving
motion-detected .avis and displaying live feeds. Note: no wifi, ethernet
only. It has worked like this for several years.
However trying with Bullseye/Bookworm turned out to be too complicated
to be worth upgrading.

--
Chris Elvidge, England
THIS IS NOT A CLUE...OR IS IT?

On 11/11/23 7:06 AM, Chris Elvidge wrote:
> On 11/11/2023 06:33, 56d.1152 wrote:
>> OK, I've been pounding at this for 10+ days now.
>>
>> What's NEEDED is for a Pi4 to read either rtsp
>> streams from security cams OR the transient
>> JPGs said cameras offer - and then put it into
>> displayable video frames.
>>
>> SOME of the cams will NOT do rtsp properly - you
>> can sometimes see them in VLC, but Motion and
>> such can't capture it properly.
>>
>> However, with RTSP and OpenCV, the big BIG problem
>> is LATENCY. I'm seeing up to like 30+ seconds. Unless
>> you use a couple of 'back-ends', the commands to shrink
>> the BUFFERS don't work - and I've not got V4L2 backend
>> to work.
>>
>> Basics - something reads the cams, either by rtsp
>> or by directly downloading those JPGs. Have been
>> using Motion - which is a great app - but it's
>> really meant for faster computers. It creates a
>> very handy MJPEG stream on a port that OpenCV can
>> easily read/crop/resize/display.
>>
>> However - LATENCY - severe !!! It's the fuckin'
>> buffering and after massive searching I've yet
>> to find a good/general/sane fix. And no I'm
>> NOT gonna re-write half the OS or Motion to
>> find success.
>>
>> Yesterday I wrote a threaded Py app that's a sort
>> of "engine" which uses curl - faster than wget -
>> to pull those JPGs out of the cams. Added "lock"
>> files for WHILE it's downloading. The display
>> app respects those locks. It all WORKS, almost
>> no latency, but there's another issue ...
>>
>> The issue is that the JPGs are replaced every
>> second, or two or three times a second depending.
>> Curl, and wget, only download WHAT THEY FIND.
>>
>> Sometimes that's a full, real, viable, JPG.
>> Sometimes it's a PARTIAL JPG ... either not
>> finished or partially overwritten by new data.
>> This inserts lots of "ugly" frames, even at
>> relatively low-FPS rates.
>>
>> My "engine" simply downloads existing JPGs from
>> the cams and puts them in an identically-named
>> files. FFMPEG - at least on the current Deb derivs -
>> the "overwrite" option does NOT work ... it INSISTS
>> on serially-numbered output JPGs, which is a crappy,
>> CPU-sucking, "solution" to deal with.
>>
>> Pi4s have FAIR cpu - but they ain't I9s.
>>
>> All that OpenCV is doing is reading the disk files,
>> or attempting rtsp, and displaying the cams in up
>> to four placed/scaled frames onscreen (btw the
>> placement does NOT work with Wayland).
>>
>> I'm attempting to free the Pis from using MJPEG
>> streams created BY the faster i9 server + motion
>> + apache. Was just displaying a web page of one
>> to four live frames via Motion. HTML plus a
>> little WebKit resize stuff worked fine. But, it's
>> DEPENDENT on the much-stronger cpu doing all
>> this stuff and current circumstances may mean
>> that stronger CPU is gonna go away. SO,
>>
>> I want the P4 display units to be "independent",
>> with "Motion" or whatever running ON them to grab
>> the security cams themselves. THEN we can display.
>>
>> SO - the TWO enemies - "Latency" from any use of
>> "Motion", or "crappy frames" using Curl.
>>
>> WORKAROUNDS :
>>
>> Use Chromium and PHP-html/WebKit/iframes to directly
>> read/scale/show the JPGs from the cams. Browsers
>> a bit of a pain to deal with and the WebKit
>> per-iframe defs are VERY hard to work with, can
>> take half a day to get everything "just right".
>> Browsers work best with MJPEG streams like
>> "Motion" creates ... but LATENCY creeps in
>> big time.
>>
>> So .......... noticed that if you bring in the
>> JPG using a browser it's like PERFECT and very
>> INSTANT. Seems they can detect a "complete" JPG
>> and download it MUCH faster than curl/wget.
>>
>> So ....... how to reproduce that "instant/perfect"
>> effect NOT involving browsers ??? What can be
>> faster than curl for downloading a JPG from a
>> remote http device - either as a straight-up file
>> or some kind of MJPEG stream ??????????
>>
>> Clearly FFox/Chromium CAN do this, so there's
>> SOME faster/better trick.
>>
>> I've spend endless hours searching on this issue,
>> and found NOTHING that really improves ...
>>
>> So, to encapsulate, VideoCapture(xxx) is not a
>> good solution for rtsp/mjpeg because of the
>> buffering problem. 'Motion' also has a serious
>> latency prob on a P4. Browser/html-php solutions
>> can work, but are a real pain in the ass to
>> deal with - no handy .config files for defining
>> sources/crops/scaling.
>>
>> And that's MY "Project Of The Week".
>>
>> I'm retiring very soon now ... but I'd LIKE to
>> get the security cam stuff for those who need to
>> see live feeds work properly/independently. Sort
>> of my "gift" to the regular-level workers and
>> a continuing legacy for PIs. The new guys can
>> learn to cope with Linux/PIs ... my "gift"
>> to those Winders-centrics. IF they screw it
>> up they WILL get ENDLESS grief - "WHERE ARE
>> MY CAMERA FEEDS ??? !!!"   :-)
>>
>> Too much ... well, better more detail than not
>> enough eh ?  :-)
>>
>> . . .
>>
>> Oh ...recent "Motion" on Deb/Pi4 ... you HAVE
>> to put the poorly-documented "start_motion_daemon=yes"
>> into "motion.conf" ... you can leave the other
>> 'daemon on" undefined or off. DO use systemctl
>> to ENABLE the daemon. I modified the systemd
>> file in /usr/lib/systemd/system/motion.service
>> to include RESTARTING on failure. DO remember
>> to do "systemctl daemon-reload" after that.
>>
>> The alt approach is to start Motion in root crontab,
>> but then you can't easily start/stop/restart. For
>> goodness I usually restart the Motion daemon at
>> least twice a day using root crontab.
>>
>
> I've got a Raspberry Pi Model B Rev 2 with both a Pi camera and a USB
> camera, Buster (10.13), lighttpd 1.4.53 and Motion 4.1.1 saving
> motion-detected .avis and displaying live feeds. Note: no wifi, ethernet
> only. It has worked like this for several years.
> However trying with Bullseye/Bookworm turned out to be too complicated
> to be worth upgrading.

I made a Pi2b doing just that the other day
(and using BookWorm). It can handle ONE webcam,
despite being old tech. Going thru motion.conf,
you can sometimes find little tweaks to speed
it up. In any case, the mjpeg stream can be
seen in a browser. Still some latency, but not
too awful.

But I'm trying to use Python stuff to do the
display - tried PIL and then OpenCV. This is
where the latency issue mostly resides.

cv2.VideoCapture(http://<stream:port) opens
the stream perfectly well, but then is where
the buffering starts and it can't handily
be negated. The authors made some decision
and that was to buffer a lot so no frames would
be lost.

Looking at 'top', the py pgm is NOT using up a
lot of CPU - it's Motion, but even that's not
too bad on a P4.

OpenCV can also directly read rtsp - but again
you get a long string of stuff in the buffer
even when the cams are like one or two FPS.

Hence my work yesterday to only use OpenCV for
sizing/display purposes and grab my cam frames
using curl threads. All OpenCV sees is what
looks like a static jpg file on disk and loads
it - no buffers.

But curl, as said, has it's problems too.

Might have to go back to a browser ... not
desired though.

On 11/11/2023 06:33, 56d.1152 wrote:
> Yesterday I wrote a threaded Py app that's a sort
> of "engine" which uses curl - faster than wget -
> to pull those JPGs out of the cams.

Use the Python requests module, it's faster than calling wget or curl.

---druck