Capture single frame image from RTSP stream

[azdeltawye]

Hello,
Sorry if this has been covered numerous times but I can't seem to get this to work...

project: I am attempting to capture a single frame from my driveway camera when a motion sensor is triggered.
Hardware:
RPi-4 running Buster OS
Lorex LNB9272 camera, 3840x2160 resolution, 20 fps, H.265 encoding

I can get a single jpeg image by entering the following url in the RPi CLI: http://192.168.xxx.yyy/cgi-bin/snapshot.cgi?1, however it takes several seconds for the camera to respond and the picture is useless because the car or person of interest is out of the field of view when the camera finally takes the picture...

So I figured I could get much faster response from the camera if I were to grab a single frame out of the RTSP stream. The RTSP command for this particular camera is: rtsp://username:password@192.168.xxx.yyy:554/cam/realmonitor?channel=1&subtype=0
After numerous Google searches I have determined this should not be too difficult by using the ffmpeg utility. So far I have tried the following strings in the RPi CLI:

Code: Select all

ffmpeg -rtsp_transport tcp -i rtsp://username:password@192.168.xxx.yyy:554/cam/realmonitor?channel=1&subtype=0 -f image2 -vf fps=fps=1 /home/pi/Pictures/test_image.jpg

ffmpeg -rtsp_transport tcp -i rtsp://username:password@192.168.xxx.yyy:554/cam/realmonitor?channel=1&subtype=0 -vframes 1 /home/pi/Pictures/test_image.jpg

ffmpeg -rtsp_transport tcp -i rtsp://username:password@192.168.xxx.yyy:554/cam/realmonitor?channel=1&subtype=0 -frames 1 -qscale 1 -f image2 /home/pi/Pictures/test_image.jpg

It seems whatever I try, the command immediately following the rtsp url is not recognized. Here is the response to the first string above:

Code: Select all

pi@RPI-2:~ $ ffmpeg -rtsp_transport tcp -i rtsp://*****:*****@192.168.***.***:554/cam/realmonitor?channel=1&subtype=0 -f image2 -vf fps=fps=1 /home/pi/Pictures/test_image.jpg
[23] 27351
bash: -f: command not found
pi@RPI-2:~ $ ffmpeg version 4.1.4-1+rpt7~deb10u1 Copyright (c) 2000-2019 the FFmpeg developers
  built with gcc 8 (Raspbian 8.3.0-6+rpi1)

It appears the RPi is activating the video stream however I cant seem to get ffmpeg to cooperate..

Any help would be greatly appreciated.
Thx

[azdeltawye]

Update;
I added the -loglevel debug command to help. Here’s what I got:

Code: Select all

 
pi@RPI-2:~ $ ffmpeg -loglevel debug -rtsp_transport tcp -y -i rstp://user:psswd@192.168.xxx.yyy:554/cam/realmonitor?channel=1&subtype=0 -frames:v 1 /home/pi/Pictures/cam7_4k.jpg
[1] 25238
bash: -frames:v: command not found
pi@RPI-2:~ $ ffmpeg version 4.1.4-1+rpt7~deb10u1 Copyright (c) 2000-2019 the FFmpeg developers
  built with gcc 8 (Raspbian 8.3.0-6+rpi1)
.
.
.
libavutil      56. 22.100 / 56. 22.100
libavcodec     58. 35.100 / 58. 35.100
libavformat    58. 20.100 / 58. 20.100
libavdevice    58.  5.100 / 58.  5.100
libavfilter     7. 40.101 /  7. 40.101
libavresample   4.  0.  0 /  4.  0.  0
libswscale      5.  3.100 /  5.  3.100
libswresample   3.  3.100 /  3.  3.100
libpostproc    55.  3.100 / 55.  3.100
Splitting the commandline.
Reading option '-loglevel' ... matched as option 'loglevel' (set logging level) with argument 'debug'.
Reading option '-rtsp_transport' ... matched as AVOption 'rtsp_transport' with argument 'tcp'.
Reading option '-y' ... matched as option 'y' (overwrite output files) with argument '1'.
Reading option '-i' ... matched as input url with argument 'rstp://user:psswd@192.168.xxx.yyy:554/cam/realmonitor?channel=1'.
Finished splitting the commandline.
Parsing a group of options: global .
Applying option loglevel (set logging level) with argument debug.
Applying option y (overwrite output files) with argument 1.
Successfully parsed a group of options.
pi@RPI-2:~ $

So it appears that its getting stuck when the stream is started and never gets to the -frames output options. And for some reason the -frames gets presented to a separate command line where the OS responds as you would expect: bash: -frames command not found.
Is this what the debugger means by ‘splitting the commandline’?

I read through the manpage manual for ffmpeg and I am pretty confident I have the correct string entered. I also completely reinstalled ffmpeg with no change in the result.

Could this be related to the h.265 encoded stream??

Next step; find an older IP cam that doesn’t support high compression codecs…

[pidd]

Try putting the whole url in double quotes

Code: Select all

 "rtsp://username:password@192.168.xxx.yyy:554/cam/realmonitor?channel=1&subtype=0"

There was also a bug in ffmpeg parsing of urls which i thought had been fixed, the url argument may need a "/" before the "?"

Code: Select all

rtsp://username:password@192.168.xxx.yyy:554/cam/realmonitor/?channel=1&subtype=0

[azdeltawye]

Thanks for the reply.
OK, I tried the suggestions both individually and together. When I added the double quotes to the url, I get the following error:

Code: Select all

 [NULL @ 0x14c6200] Opening 'rstp://user:psswd@192.168.xxx.yyy:554/cam/realmonitor/?channel=1&subtype=0' for reading
rstp://user:psswd@192.168.xxx.yyy:554/cam/realmonitor/?channel=1&subtype=0: Protocol not found
Did you mean file:rstp://user:psswd@192.168.xxx.yyy:554/cam/realmonitor/?channel=1&subtype=0?
pi@RPI-2:~ $

And when I add the additional forward slash prior to the ? it still gives the original result: command not found...

[pidd]

You have rstp instead of rtsp

[azdeltawye]

Wow. I can't believe I did that...

The double quote worked!

Thank you very much!!

[azdeltawye]

Followup problem/question:

Looking at the pictures captured, I immediately noticed the filesize seemed a bit small; 900k for a 3840x2160 and around 500k for a cropped 1920x1080. Additionally the quality of the pic is less than ideal. I attempted to mitigate this by adding the quality modifier to the output (-q:v 2) but that only slightly improved image quality. What am I missing?

I've seen the command (-c:v lib265) used for re-encoding hevc streams but I think I need to properly decode the h.265 to get the maximum image quality. Right?

Again, any help would be much appreciated.
Thx

[pidd]

Are you capturing the right rtsp stream, some devices put out a high quality and a low quality stream. You probably got that covered but I had to mention.

Video stills are never as good as still stills, far more compression used.

[azdeltawye]

Thx for the reply.

Yes, the 'subtype=0' at the end of the rtsp url tells the cam to use the main-stream instead of the sub-stream feed. Main stream is set to 3840x2160 @ 20 fps and sub stream is 704x480 @ 15 fps.

Yeah, makes sense about the quality of a video stream being less than a still. Especially with the h.265 compression and all. I can live with the quality, I was just hoping for crystal clear...