From Newsgroup: comp.os.linux.misc

Most of you will find this uninteresting.

Little Python app for capturing security cams, USB
cams AND commercial.

Used OpenCV2

SOME of my cams feed through "Motion" - which produces
mjpeg streams on a given port. Dealing with those is
no problem.

However a few cams are commercial units, they do
not deliver on a port (unless it's RTSP, which is
a whole other long-latency pain in the ass).

My commercial cams DO offer a couple of jpg images,
one for the low-rez - fully buffered - and one for
the high-rez (may not be complete).

For the 'motion' ports it's easy ...
capture=cv2.VideoCapture(URL)
ret,frame=capture.read()
gets you a frame you can plug into a 'film'
defined by :
mmm=cv2.VideoWriter_fourcc(*'mp4v')
film=cv2.VideoWriter(tStr,mmm,FPS,(vidRezX,vidRezY))
Finally you collect individual frames by
rval,frame = vv.read()
and then
film.write(frame)

Plenty of docs on this.

HOWEVER ... for those cams we have to capture
pre-existing jpg's from ... this maybe possibly
collects exactly ONE frame and then nada.

You're basically trying to read a jpg off
the Net.

Docs suggest using "urllib.request" and a few
other horrible binary-related lines. NEVER got
this to work ... half a dozen or more obtuse
errors that are not informative. This is kinda
like "wget", but more Python.

Now cv2.VideoWriter() can directly read network
jpgs.

Tried that. Kept getting one frame, or no frame,
videos.

It works very very well for those mjpeg streams though.

Turns out, for reading network jpgs you have to RE-DO
the 'capture' stuff EVERY time you want a frame. The
'capture' doesn't LAST more than one use.

Now I kludged this with a 'if ".jpg" in vidURL :"
thing ... so IF we're trying to read a jpg direct
it does all the frame capture, then re-does the
whole capture thing.
if ".jpg" in vidURL :
capture.release()
capture=cv2.VideoCapture(xxx)

THEN it works for such jpgs. Gotta do that EVERY
time you grab one jpg to use as a movie frame.

Yea, it's kludgy ! Hate it.

I *think* pillow/willow offers some alt, but they
are not as generally versatile as cv2 stuff.

Once you DO get a frame you can then resize/mutate
it any way you want before 'film.write(frame)'

I explicitly resize ... though only to what the
camera frame is SUPPOSED to be. Cleans up any
tiny irregularities that might jink the save
process.

ANYway ... sometimes 'simple' stuff has nasty
weird GLITCHES. I found this one when I went
to 'improve' the capture/save app. As said,
'motion' streams worked perfectly, but NOT
the outright jpg captures. Drove me nuts and
it took a lot of experimentation to see where
it was going wrong.

This is the Real World. Even 'simple' can
screw you. This took me two days to diagnose
and work around. Online docs don't really
address the issue.

MOST of the cams I wanted to record went thru
'motion' ... and had been using just those, not
by intent. However adding the jpgs revealed
the problem.

Alt worst case, you COULD use 'wget' to pull
down a jpg and then the easier cv2 stuff to
insert it into a movie. 'wget' works, but
it's sometimes a bit slow and jerky.

Fun Fun Fun !

Oh well, it all works now ... if not as crisp
and cleanly as I'd like.

More fun ... dealing with RTSP ... that works
too. Have ONE cam I do that with because I want
the AUDIO - and OpenCV2 does not capture audio.
Another issue/saga :-)

But most of you won't care.

--- Synchronet 3.22a-Linux NewsLink 1.2