misterdata
n3wb
- Joined
- Apr 24, 2016
- Messages
- 2
- Reaction score
- 3
Thanks for your reply - I have used no port, Port 1554 and 554 with the same result
Raspbery Pi2 Camera Monitor w/Rpisurv
- Thread starter nayr
- Start date
cball
Young grasshopper
You Need to have a port in the config, maybe that's the problem:
"rtsp://user
ass@192.168.42.23:554/cam/realmonitor?channel=1&subtype=1"
Why did you delete the original post? Now my answer, doesn't make sense.
"rtsp://user
ass@192.168.42.23:554/cam/realmonitor?channel=1&subtype=1"Why did you delete the original post? Now my answer, doesn't make sense.
misterdata
n3wb
- Joined
- Apr 24, 2016
- Messages
- 2
- Reaction score
- 3
My damn mobile ripped me off!! :-( I alopogize for my stupid behavior - wanted to quote, but deleted the post...You Need to have a port in the config, maybe that's the problem:
"rtsp://user
Why did you delete the original post? Now my answer, doesn't make sense.
OK I TRY it AGAIN (in short):
STATUS:
Raspi: new Pi3, static network, HP-HDMI display (HP w2558hc), GPU got 512MB.
Surveillance: 1 old dahua dvr (ip..104), 1 newer dahua dvr (ip...105), IP-china cam (ip...108)
PC: all streams can be viewed with smartPSS and old PSS from dahua
Android: all streams can be viewed with ipcamviewer from guhgle-playstore
Raspi: streams can be viewed with
but starting RPISURV (after a bunch of solved beginner´s mistakes like formatting...) now runs into error, which comes on screen and similar in the logfile:
2016/04/24 05:27:59 - l_default - ERROR - 192.168.2.108 : 1554 Not Connectable (failed socket connect)
2016/04/24 05:27:59 - l_default - ERROR - 192.168.2.105 : 1554 Not Connectable (failed socket connect)
2016/04/24 05:27:59 - l_default - ERROR - 192.168.2.104 : 1554 Not Connectable (failed socket connect)
2016/04/24 05:27:59 - l_default - ERROR - 192.168.2.104 : 1554 Not Connectable (failed socket connect)
2016/04/24 05:27:59 - l_default - ERROR - No connectable streams detected
the config file is:
essentials:
#These are the rtsp streams you want the program to display
#The streams will be displayed in the order you present them here
rtsp_urls:
#Dlink dcs-5222l example
#- "rtsp://<user>:<password>@<ip or dnsname>:<port>/play1.sdp"
#foscam-fi9821w example
#- "rtsp://<user>:<password>@<ip or dnsname>:<port>/videoMain"
#Dahua IPC-HDW4200S example or IPC-HDW4300S
- "rtsp://knock:knock@192.168.2.108:1554/cam/realmonitor?channel=1&subtype=1&max_fps=10&buffer=4000"
- "rtsp://knock:knock@192.168.2.105:1554/cam/realmonitor?channel=2&subtype=1"
- "rtsp://knock:knock@192.168.2.104:1554/cam/realmonitor?channel=3&subtype=1"
- "rtsp://knock:knock@192.168.2.104:1554/cam/realmonitor?channel=4&subtype=1"
#How many columns you want the program to use, it will autocalculate the amount of row needed based on the resolution of your screen
nr_of_columns: "2"
When stream is called from terminal, it works with (The port 554 I tried with 1554, 554, without port, all worked fine DIRECTLY.)
pi@Pi2:/ $ omxplayer --win "0 21 640 501" --live 'rtsp://admin:big@bang:554/cam/realmonitor?channel1&subtype1'
Invalid framerate 90000, using forced 25fps and just trust timestamps
Video codec omx-h264 width 704 height 576 profile 66 fps 25.000000
Subtitle count: 0, state: off, index: 1, delay: 0
V
ortSettingsChanged: 704x576@24464.00 interlace:0 deinterlace:0 anaglyph:0 par:1.00 display:0 layer:0 alpha:255 aspectMode:0...hope I´ll never deleted my posts again
The port 554 I tried with 1554, 554, without port, all worked fine DIRECTLY.
UPDATE: SOLVED!
I re-updated all components of the Pi3, tried all the ports again, 554 works fine!
Thank you very much for the fine work! Now I´ll try to catch all the streams (8 streams work right now well)
Last edited by a moderator:
Hi,
In the newest version of omxplayer you have an argument that can be used to enable rtsp over tcp without patching the source code of omxplayer like it was done before
I added a new option to rpisurv to make use of this new option enable rtsp_over_tcp. This option resolves some smearing effects on some setups.
To be able to use the new option you need to convert to the new option of configuring rtsp streams. The rtsp_urls config option should still work but is deprecated.
(do not copy paste this as you would loose the required tabs that is required by yaml, use https://github.com/SvenVD/rpisurv/blob/master/surveillance/conf/surveillance.yml instead )
essentials:
#These are the rtsp streams you want the program to display
#The streams will be displayed in the order you present them here
camera_streams:
#Dlink dcs-5222l example
- rtsp_url: "rtsp://<user>:<password>@<ip or dnsname>:<port>/play1.sdp"
#Enable this option if you want the rtsp stream to stream over tcp instead of udp, this may solve a "smearing" effect on some setups. Defaults to false
#Note that you need a version of omxplayer older then 14 March 2016 for this option to work
rtsp_over_tcp: true
#Foscam-fi9821w example
- rtsp_url: "rtsp://<user>:<password>@<ip or dnsname>:<port>/videoMain"
#Dahua IPC-HDW4200S example or IPC-HDW4300S
- rtsp_url: "rtsp://<user>:<password>@<ip or dnsname>:<port>/cam/realmonitor?channel=1&subtype=1"
In the newest version of omxplayer you have an argument that can be used to enable rtsp over tcp without patching the source code of omxplayer like it was done before
I added a new option to rpisurv to make use of this new option enable rtsp_over_tcp. This option resolves some smearing effects on some setups.
To be able to use the new option you need to convert to the new option of configuring rtsp streams. The rtsp_urls config option should still work but is deprecated.
(do not copy paste this as you would loose the required tabs that is required by yaml, use https://github.com/SvenVD/rpisurv/blob/master/surveillance/conf/surveillance.yml instead )
essentials:
#These are the rtsp streams you want the program to display
#The streams will be displayed in the order you present them here
camera_streams:
#Dlink dcs-5222l example
- rtsp_url: "rtsp://<user>:<password>@<ip or dnsname>:<port>/play1.sdp"
#Enable this option if you want the rtsp stream to stream over tcp instead of udp, this may solve a "smearing" effect on some setups. Defaults to false
#Note that you need a version of omxplayer older then 14 March 2016 for this option to work
rtsp_over_tcp: true
#Foscam-fi9821w example
- rtsp_url: "rtsp://<user>:<password>@<ip or dnsname>:<port>/videoMain"
#Dahua IPC-HDW4200S example or IPC-HDW4300S
- rtsp_url: "rtsp://<user>:<password>@<ip or dnsname>:<port>/cam/realmonitor?channel=1&subtype=1"
Updating follows the same steps as installing from scratch
see "how to get started" on https://github.com/SvenVD/rpisurv/blob/master/README.md
nayr
IPCT Contributor
no, not unless you can set the substream to h264
nayr
IPCT Contributor
Get a h2645 Dahua NVR and hook it to a TV
GuitarKin
Getting the hang of it
I already have NVR5208 4ks2 8p, but it is my "technical room" and distance to my TV is problem.
nayr
IPCT Contributor
thats what they make long cables for.. I have mine on a 35ft HDMI cable down in my basement server room.. then a usb extension cable of simuliar length has a wireless mouse plugged in.
GuitarKin
Getting the hang of it
Maybe I'll try that. Thanks!
nayr
IPCT Contributor
without a network interface the pi zero is absolutely unsuitable for this; and yeah omxplayer can decode hik streams as long as they are h264 and not h264+ or h265
Should be OK with a USB WiFi dongle though.
I did try this with a pi zero when they were first released but I recall having the corruption problems shown on the issue tracker, I also seem to recall that it displayed a pink screen after some seconds and had increasing amounts of delay from the live feed.
I'll have to get another pi and try again
I did try this with a pi zero when they were first released but I recall having the corruption problems shown on the issue tracker, I also seem to recall that it displayed a pink screen after some seconds and had increasing amounts of delay from the live feed.
I'll have to get another pi and try again
nayr
IPCT Contributor
no it wont, Wireless connectivity is not going to work well.. if you hook another pi up to wifi expect the exact same shitty performance.. all the problems you describe are very likely w/out a wired ethernet connection.
a wired ethernet connection is a requirement; otherwise dont even bother.
Sorry to ask dumb question... but is this a new file "surveillance.yml" in the directory? - or do you copy this contents into this via sudo nano /etc/rpisurv?
Or does that file no longer exsist with the new version of omxplayer?
So - I cannot quite get this to work but am close.... This is a HIK camera. Stream 1 would not work.
I can get the camera to come up on the Pi with -
sudo omxplayer --win "0 21 640 501" --live 'rtsp://admin:12345@192.168.1.130:554/Streaming/Channels/2'
When I reboot the Pi I get this -
-- l_default -- DEBUG -- autodetected resolution of ['1824' , '984']
Traceback (most recent call last):
File "surveillance.py", line 273, in <module>
KeyError: 'advanced'
Any ideas?
I can get the camera to come up on the Pi with -
sudo omxplayer --win "0 21 640 501" --live 'rtsp://admin:12345@192.168.1.130:554/Streaming/Channels/2'
When I reboot the Pi I get this -
-- l_default -- DEBUG -- autodetected resolution of ['1824' , '984']
Traceback (most recent call last):
File "surveillance.py", line 273, in <module>
KeyError: 'advanced'
Any ideas?
Here is my config file - Thanks in advance for any/all help.
essentials:
#These are the rtsp streams you want the program to display
#The streams will be displayed in the order you present them here
camera_streams:
#Hik Camera
- rtsp_url: "rtsp://admin:12345@192.168.1.130:554/Streaming/Channels/2"
#Enable this option if you want the rtsp stream to stream over tcp instead of udp, this may solve a "smearing" effect on some setups. Defaults to false
#Note that you need a version of omxplayer older then 14 March 2016 for this option to work
rtsp_over_tcp: true
#How many columns you want the program to use, it will autocalculate the amount of row needed based on the resolution of your screen
nr_of_columns: "2"
#rpisurv detects the connectable streams on startup,
#if this option is enabled it will keep the first calculated layout for the lifetime of the rpisurv running even if some cameras go down and come up, instead of redrawing the screen
#When this option is set to True, rpisurv ignores all cameras configured that were not connectable when rpisurv was started
keep_first_screen_layout: False
#These are fallbacks if autodection fails;
#Normally you do not need to configure these
fallbacks:
resolution:
width: "1920"
height: "1080"
essentials:
#These are the rtsp streams you want the program to display
#The streams will be displayed in the order you present them here
camera_streams:
#Hik Camera
- rtsp_url: "rtsp://admin:12345@192.168.1.130:554/Streaming/Channels/2"
#Enable this option if you want the rtsp stream to stream over tcp instead of udp, this may solve a "smearing" effect on some setups. Defaults to false
#Note that you need a version of omxplayer older then 14 March 2016 for this option to work
rtsp_over_tcp: true
#How many columns you want the program to use, it will autocalculate the amount of row needed based on the resolution of your screen
nr_of_columns: "2"
#rpisurv detects the connectable streams on startup,
#if this option is enabled it will keep the first calculated layout for the lifetime of the rpisurv running even if some cameras go down and come up, instead of redrawing the screen
#When this option is set to True, rpisurv ignores all cameras configured that were not connectable when rpisurv was started
keep_first_screen_layout: False
#These are fallbacks if autodection fails;
#Normally you do not need to configure these
fallbacks:
resolution:
width: "1920"
height: "1080"