Access live stream from camera direct, through HIKVision NVR?

[Robert G.]

I have a 16 channel HIKVision camera, with virtual host enabled.

If I want to access a camera directly through a web browser, I can access like this:

http://192.168.250.9:65010

Just the IP address of the NVR and port to connect to. I can configure camera settings, view the live stream via the browser etc. etc.

I use iVMS software on my PC or tablets to stream footage. I configure them to talk directly to the NVR and get the stream just fine.

However, is it possible to connect directly to the camera and access the video streams? Rather than connecting to the NVR, I would like to access the cameras directly via the virtual host feature? Can that be done? I have tried a couple of different ways in iVMS but have not had any luck.

 

[alastairstevenson]

However, is it possible to connect directly to the camera and access the video streams?

As an experiment to avoid using the NATed feature of virtual host - maybe try this - though I don't know if it would work with iVMS. Easy enough to test :

Essentially it's a matter of some changes to the networking -
Use the NVR PoE interface IP address as the default gateway for the camera. This is usually 192.168.254.1
Inform the LAN router / gateway where to send traffic for the cameras by adding a static route, something like :
"For <NVR-PoE_ports_network_address> use <NVR_LAN_Interface> as the gateway."
The network address would usually be 192.168.254.0/24
Then access the camera at it's native 192.168.254.x IP address.
Ping it, check it out in the browser etc.

 

[CoreyX64]

Outside of iVMS you can directly stream via the RTSP streaming URL but that is not something that would work within iVMS.

If you are trying to break out individual cameras on the PoE side of the network and treat them as independent camera hosts on the main network, that will not work over the virtual host feature using iVMS as a viewer/client. The point of that is mostly for direct camera config through the NVR as a means of fine tuning settings (some camera settings do not appear on the NVR config side, so this is the way to adjust them).

Virtual host is a glorified version of port forwarding across subnets, except it only forwards/filters port 80 and remaps them to the the 650xx ports on the recorder. RTSP (554) also works as well and is a direct pass through

 

[alastairstevenson]

Virtual host is a glorified version of port forwarding across subnets,
and remaps them to the the 650xx ports on the recorder. RTSP (554) also works as well and is a direct pass through

Enabling Virtual Host implicitly turns on the Linux kernel 'ip_forward' facility - not to be confused with 'port forwarding' which is something entirely different.
In addition to that forwarding capability, Virtual Host also creates a NAT facility within the iptables (actual the newer xtables) program to create the 6500x mapping on top of the native NVR LAN interface IP address with no extra network configuration.

But it's certainly possible to use the Linux kernel IP_forward facility with a little extra network configuration, as I indicated in Post #2
I don't know if this will work with iVMS for the OP, I've not tried it, but easy enough to test.

except it only forwards/filters port 80

Check out this worked example of directly accessing a Hikvision camera that's on an NVR PoE port, with no other network connections to the NVR PoE ports.
You can see that it's not just port 80 that's accessible.
SSH access works OK, as do the other ports.

alastair@PC-I5 ~ $ ifconfig
enp0s31f6: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.1.99  netmask 255.255.255.0  broadcast 192.168.1.255
        inet6 fe80::82bd:bd7b:2dda:3f9e  prefixlen 64  scopeid 0x20<link>
        ether d0:50:99:97:b3:12  txqueuelen 1000  (Ethernet)
        RX packets 658330  bytes 855606567 (855.6 MB)
        RX errors 0  dropped 1  overruns 0  frame 0
        TX packets 279504  bytes 36539342 (36.5 MB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 16  memory 0xdf100000-df120000 

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 17761  bytes 1766182 (1.7 MB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 17761  bytes 1766182 (1.7 MB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

alastair@PC-I5 ~ $ nmap 192.168.1.214
Starting Nmap 7.80 ( https://nmap.org ) at 2021-02-14 19:10 GMT
Nmap scan report for 192.168.1.214
Host is up (0.0075s latency).
Not shown: 997 closed ports
PORT     STATE SERVICE
80/tcp   open  http
554/tcp  open  rtsp
8000/tcp open  http-alt

Nmap done: 1 IP address (1 host up) scanned in 0.13 seconds
alastair@PC-I5 ~ $ nmap 192.168.254.2
Starting Nmap 7.80 ( https://nmap.org ) at 2021-02-14 19:10 GMT
Nmap scan report for 192.168.254.2
Host is up (0.0042s latency).
Not shown: 994 closed ports
PORT     STATE SERVICE
22/tcp   open  ssh
80/tcp   open  http
443/tcp  open  https
554/tcp  open  rtsp
8000/tcp open  http-alt
8443/tcp open  https-alt

Nmap done: 1 IP address (1 host up) scanned in 1.19 seconds
alastair@PC-I5 ~ $ traceroute 192.168.254.2
traceroute to 192.168.254.2 (192.168.254.2), 64 hops max
  1   192.168.1.214  0.455ms  0.369ms  0.255ms
  2   192.168.254.2  0.832ms  1.134ms  1.070ms
alastair@PC-I5 ~ $ ssh admin@192.168.254.2
The authenticity of host '192.168.254.2 (192.168.254.2)' can't be established.
ECDSA key fingerprint is SHA256:V25OxerFJhDBDxSAvAJGrJsP6tPmvNB1oevICQA8Wpk.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '192.168.254.2' (ECDSA) to the list of known hosts.
admin@192.168.254.2's password:
BusyBox v2.0.0-621376 Protect Shell (psh)
Enter 'help' for a list of davinci system commands.

# prtHardInfo
Start at 2021-02-14 19:09:01
Serial NO :DS-2CD2087G2-L20210114AAWRF42557178
V5.5.160 build 210209
NetProcess Version: 1.9.0.765278 [16:42:24-May 27 2020]
Path: /Camera/Platform/Branches/branches_FSP_network_protocol/BASE/FSP_network_multi
Last Changed Rev: 869076
Last Changed Date: 2020-05-25 14:35:43 +0800 (Mon, 25 May 2020)

Sec Version: 0.0.1 [18:56:30-May  7 2020]
Path: /Camera/Platform/Branches/branches_FSP_network_protocol/sec/FSP_network_security_for_multi_V1.0
Last Changed Rev: 786965
Last Changed Date: 2020-03-25 10:09:48 +0800 (Wed, 25 Mar 2020)

Db Encrypt Version: 131072
hardwareVersion    = 0x0
hardWareExtVersion    = 0x0
encodeChans        = 1
decodeChans        = 1
alarmInNums        = 0
alarmOutNums        = 0
ataCtrlNums        = 0
flashChipNums        = 0
ramSize            = 0x400
networksNums        = 1
language            = 1
devType            = 0x232f4
net reboot count    = 0
vi_type            = 96
vi_type2            = 96
lens_type            = 0
lens_type2            = 0
gps_info            = 0
audioInSupport        = 2
abfType            = 0
firmwareCode        = 0000000200000100000000010dc1bc6f000000010000000100000002ffffffff050500a000150209000232f4
shieldSupport        = 0
IRSupport            = 10
bFillLightType2    = 0
Path: /Camera/Platform/Branches/branches_frontend_software_platform/IPC_develop_branch/ipc_baseline/bugfix_fault_G3_sec
Last Changed Rev: 1150249
Last Changed Date: 2021-02-07 19:41:00 +0800 (Sun, 07 Feb 2021)


#

 

[CoreyX64]

I meant in the sense of taking one port from one device and both forwarding and remapping it to a different port on the NVR. As that’s exactly what it does from the end user perspective. Underneath I have no clue.

iVMS is always looking for port 8000 (or whatever you have your SDK port set to) and that’s what you would need to pass through. Additionally, your options of altering the firmware on the NVR to allow that are virtually non-existent if it isn’t already allowing it through (it’s not, because that would conflict with NVR ports). At that rate, an external PoE switch is more cost effective to solve this issue.

What might be worth trying is setting each camera to its own SDK port (NVR 8000, cam1 8001, cam2 8002, etc) and iVMS has a different device using the NVR IP and a different Port for each camera, using that as the channel selector.

Haven’t tested this as I have no need to dial in each camera separately (if so, it’s networked accordingly), but that’s the only thing I can think of that would work

 

[alastairstevenson]

iVMS is always looking for port 8000 (or whatever you have your SDK port set to) and that’s what you would need to pass through.

Enabling Virtual Host passes all ports through.
Check out the nmap result of the camera on the NVR, accessed directly via the camera's native IP address of 192.168.254.2, from a PC on the LAN :

alastair@PC-I5 ~ $ nmap 192.168.254.2
Starting Nmap 7.80 ( https://nmap.org ) at 2021-02-14 19:10 GMT
Nmap scan report for 192.168.254.2
Host is up (0.0042s latency).
Not shown: 994 closed ports
PORT     STATE SERVICE
22/tcp   open  ssh
80/tcp   open  http
443/tcp  open  https
554/tcp  open  rtsp
8000/tcp open  http-alt
8443/tcp open  https-alt

Additionally, your options of altering the firmware on the NVR to allow that are virtually non-existent

There is no need to do any firmware alterations.

What might be worth trying is setting each camera to its own SDK port (NVR 8000, cam1 8001, cam2 8002, etc) and iVMS has a different device using the NVR IP and a different Port for each camera, using that as the channel selector.

No need, as each camera has it's own unique IP address.
Remember, this is not 'port forwarding' where you'd need to do that, it's what the NVR Linux kernel does when Virtual Host is enabled.

Test it for yourself, you might be surprised.
It works as stated.

 

[CoreyX64]

I have an I series unit and this does not work. Not pingable, scannable, or reachable in any capacity and cameras are all on 192.168.254.0/24. I’ve never know this to work either. But even if that were the case a client computer is not going to be able to reach a device on another subnet unless it’s NIC is reconfigured for that subnet, or routing between subnets is possible (L3 switching, nothing consumer at all)

 

[alastairstevenson]

I have an I series unit and this does not work. Not pingable, scannable, or reachable in any capacity and cameras are all on 192.168.254.0/24

I'm guessing that the NVR-connected camera doesn't have the NVR PoE interface IP address as the default gateway.
That's necessary in order for the routing to work. It needs to have a valid gateway to forward packet to another subnet.

But even if that were the case a client computer is not going to be able to reach a device on another subnet unless it’s NIC is reconfigured for that subnet, or routing between subnets is possible (L3 switching, nothing consumer at all)

Not so - if the device default gateway (ie usually the LAN router) is informed where to forward the packets for devices on network 192.168.254.0 - via the NVR LAN interface - it no longer sends these to the 'next hop' - ie out to the internet, it sends them to the NVR LAN interface.
No reconfiguration of a PC NIC required - it's just about having the routing correctly set on the router.

 

[CoreyX64]

The gateway is set correctly on the cameras but router is certainly not set with any static routes to direct traffic to the NVR interface so that makes sense. That’s not something that would ever be done out of the box except in cases of OP where he explicitly has a need for direct access traversing across the recorder. The question becomes does his networking hardware support it. I don’t use a whole lot of residential stuff so wouldn’t have a clue as to support for that. With “cloud” products and mesh wireless products taking the world by storm the past several years, I’ve operated under the assumption things have become so consumerized, such config options are thin on modern hardware.

 

[SgtHobNob]

Sorry to bring an old thread alive but did you have any luck Robert?

I have a DS-7608NXI-I2 / 8P/S NVR and 2x DS-2CD2387G2-LU cameras. I would like to use the regular motion detect/smart events to record to the NVR, but I also need to access the cameras third 1080p stream for Scrypted (HomeKit Secure video integration) which I've enabled by changing the cameras VCA resource to "Monitoring". My idea was to then use the "smarter" AcuSense NVR perform the human/vehicle detection and record, whilst allowing a raspberry pi with Scypted to monitor the 1080p feed.

I did have this working without the NVR, but it meant no local AI recording which I prefer as a fall back to Apple HomeKit.

Right now I'm doing it in a weird way which I don't think is ideal, I've created a 'custom protocol' for the cameras which uses the cameras RTSP port instead of the management port, as a result I get the correct Main and sub stream but its not limiting what smarts I can do as its using the NVR as apposed to the camera for the third sub stream (the NVR doesn't support 2 sub streams, ive essentially made it ignore the cameras 2nd lower res stream and forcing it to use the 3rd 1080p one).

I know this is quite ramble and confusing and probably warrants it's own topic, but I've found this one to be the closest problem to what I have and alastairstevenson's posts helped me create rules in my Unifi USG to forward the NVR ip addresses to the port, I can access the cameras web interface via this but not the RTSP streams which would I believe solve all my problems, but from what CoreyX64 has mentioned it doesn't look like this is actually possible.

Thanks in advance for any help anyone can offer.

 

[Robert G.]

Sorry to bring an old thread alive but did you have any luck Robert?

I have a DS-7608NXI-I2 / 8P/S NVR and 2x DS-2CD2387G2-LU cameras. I would like to use the regular motion detect/smart events to record to the NVR, but I also need to access the cameras third 1080p stream for Scrypted (HomeKit Secure video integration) which I've enabled by changing the cameras VCA resource to "Monitoring". My idea was to then use the "smarter" AcuSense NVR perform the human/vehicle detection and record, whilst allowing a raspberry pi with Scypted to monitor the 1080p feed.

I did have this working without the NVR, but it meant no local AI recording which I prefer as a fall back to Apple HomeKit.

Right now I'm doing it in a weird way which I don't think is ideal, I've created a 'custom protocol' for the cameras which uses the cameras RTSP port instead of the management port, as a result I get the correct Main and sub stream but its not limiting what smarts I can do as its using the NVR as apposed to the camera for the third sub stream (the NVR doesn't support 2 sub streams, ive essentially made it ignore the cameras 2nd lower res stream and forcing it to use the 3rd 1080p one).

I know this is quite ramble and confusing and probably warrants it's own topic, but I've found this one to be the closest problem to what I have and alastairstevenson's posts helped me create rules in my Unifi USG to forward the NVR ip addresses to the port, I can access the cameras web interface via this but not the RTSP streams which would I believe solve all my problems, but from what CoreyX64 has mentioned it doesn't look like this is actually possible.

Thanks in advance for any help anyone can offer.

I have never been able to figure out a way to directly access the camera behind the NVR and get audio.

I can connect to the RTSP stream, which might be something like

http://192.168.250.9:65010

but there is no audio. I use several different streaming software packages and connect to the RTSP port via the NVR... just no audio :-(

I know it is somehow possible, because if I use Internet explorer I can get the sound. It is annoying as I would like to get the sound.

 

[Kdill]

The only way I was able to do this somewhat was to connect a cable to one of the ports on the nvr and patched it to a second NIC on my server and just changed the ip/gateway to line up with the nvr. It could probably be patched into a network with a decent router

 

[tech_junkie]

I have never been able to figure out a way to directly access the camera behind the NVR and get audio.

I can connect to the RTSP stream, which might be something like

http://192.168.250.9:65010

but there is no audio. I use several different streaming software packages and connect to the RTSP port via the NVR... just no audio :-(

I know it is somehow possible, because if I use Internet explorer I can get the sound. It is annoying as I would like to get the sound.

set up what I would call a "downstream router without NAT"
For example on a Hikvision NVR that has 192.168.254.1 as its cam interface address with its camera pool from 192.168.254.2 to 192.168.254.17 (16 port)
home network ip for the NVR is 192.168.1.20
use a hard wire router like a TPlink ER605
WAN connection on the home network,
Router's LAN: address 192.168.254.254 subnet mask 255.255.255.0
DHCP on, but assigned ip range 192.168.254.50-192.168.254.100
Firewall OFF


Program this router away from the network (plug in a computer in it ) then install the WAN port on the home internet network and the LAN on the camera network.
Now you should be able to access the camera at its ip address (192.168.254.6 for example) from anywhere in the home internet network.

If the connection from home internet doesn't work, then you must include it in the higher subnet by changing the home internet's router to a subnet mask of 255.255.0.0

Not all routers are the same in this behavior

 

[tekguru]

Hi guys it looks like I've got the same issue here. Hoping someone more knowledgeable than myself over networking can help. My cameras are on a separate network hosted on the NVR (192.168.254.x) from my main network. The main network is 192.168.1.x with the NVR itself being 192.168.1.77. To try to access the cameras from the main network I've put in place a static route on the router sending all traffic for each camera to go via the NVR (see attached), but when I look to validate the RTSP steam via VLC (rtsp:/192.168.254.4/Streaming/Channels/103/ it is unable to connect. Any assistance as to what I need to do / change would be appreciated.

I have tried changing the subnetmask to 255.255.255.0 (/24) and it makes no difference. I too am looking to get the third stream accessed so I can use it with Scrypted. My NVR looks not to be able to support enabling the third stream.
If case anyone needs the info I'm working on an Apple Mac and Netgear Orbi router.
Thanks in advance.

 

[alastairstevenson]

In addition to the static route, you need to configure the cameras to use the NVR PoE interface as the gateway, usually 192.168.254.1
To inhibit the NVR from changing that back, you'll need to set the NVR PoE channel to Manual instead of Plug&Play.

 

[tech_junkie]

Hi guys it looks like I've got the same issue here. Hoping someone more knowledgeable than myself over networking can help. My cameras are on a separate network hosted on the NVR (192.168.254.x) from my main network. The main network is 192.168.1.x with the NVR itself being 192.168.1.77. To try to access the cameras from the main network I've put in place a static route on the router sending all traffic for each camera to go via the NVR (see attached), but when I look to validate the RTSP steam via VLC (rtsp:/192.168.254.4/Streaming/Channels/103/ it is unable to connect. Any assistance as to what I need to do / change would be appreciated.
View attachment 141829
I have tried changing the subnetmask to 255.255.255.0 (/24) and it makes no difference. I too am looking to get the third stream accessed so I can use it with Scrypted. My NVR looks not to be able to support enabling the third stream.
If case anyone needs the info I'm working on an Apple Mac and Netgear Orbi router.
Thanks in advance.

well, you suppose to go to 192.168.1.77. , the ip of the NVR, log in and see it.
no extra software is really needed to view an NVR other than a browser. When you have several NVRs on a network, then a VMS software Like IVMS is used. But yes, you can connect IVMS to one NVR as well to get the camera.

Normally the cams are on a different network segment than the NVR's network connection. Because the cam ports are on a separate Ethernet interface inside the NVR, usually running at 100Mbps while the LAN interface runs at 1000Mbps. Some NVRs do have both interfaces bonded, but you would have to use a netmask that would encompass all network segments like 255.255.0.0 but if the media clock is isolated, you would have to plug a cam port into the lan side to access the camera.

But I strongly don't recommend the above because it removes a layer of protection, but if you do , keep in mind it may effect network performance as two network clocks (one @ 100Mb, one @1Gb) on the same cable when you connect to a camera on the cam Network.

 

[tekguru]

Okay thanks for the reply, I'm a newbie to all of this. The NVR is set as:





The camera I'm testing with is set as:



I'm not sure what I need to 'you need to configure the cameras to use the NVR PoE interface as the gateway'.

I can access the web logon for the camera without any problems but can't get the rtsp stream to validate via VLC, it refuses to connect. So far I've tried:

rtsp:/192.168.254.4/Streaming/Channels/103/
rtsp:/192.168.254.4:65003/Streaming/Channels/103/
rtsp:/192.168.254.4:65003/Streaming/Channels/101/
rtsp:/192.168.254.4/Streaming/Channels/101/
rtsp:/192.168.254.4:65003
rtsp:/192.168.254.4:554
rtsp:/192.168.254.4:554/Streaming/Channels/101/

 

[tech_junkie]

I can access the web logon for the camera without any problems but can't get the rtsp stream to validate via VLC, it refuses to connect. So far I've tried:

most cameras when you connect them to an NVR the rtsp server in them are disabled or will not work until a new user is put into a camera.

Why are you using VLC anyways?
You suppose to use IVMS-4200 and access the cameras securely with that software.

 

[tech_junkie]

Okay thanks for the reply, I'm a newbie to all of this. The NVR is set as:

View attachment 141831

View attachment 141832

The camera I'm testing with is set as:

View attachment 141833

I'm not sure what I need to 'you need to configure the cameras to use the NVR PoE interface as the gateway'.

I can access the web logon for the camera without any problems but can't get the rtsp stream to validate via VLC, it refuses to connect. So far I've tried:

rtsp:/192.168.254.4/Streaming/Channels/103/
rtsp:/192.168.254.4:65003/Streaming/Channels/103/
rtsp:/192.168.254.4:65003/Streaming/Channels/101/
rtsp:/192.168.254.4/Streaming/Channels/101/
rtsp:/192.168.254.4:65003
rtsp:/192.168.254.4:554
rtsp:/192.168.254.4:554/Streaming/Channels/101/

What you have is correct for a typical Hikvision system.

rtsp is not a good method to access ip cams

The NVR has two ethernet interfaces, one that connects to the lan and the other is connected to the built in poe switch for the camera ports and forms an isolated 100Mbps network.

 

[tekguru]

Good to know what I have set is correct.

I'm actually trying to set up Scrypted on my NAS (within Docker) so I can add my cameras into the Apple Homekit system. For that I need to use an rtsp feed which is viable. I can access the streams on the NVR using a stream such as rtsp:/192.168.1.77/Streaming/Channels/301/ (camera 1, stream 1) (in VLC) but the NVR only supports streams 1 & 2 which do not carry the right resolution. The correct resolution is on stream 3 and to get to that stream I need to access it on the camera directly, and that's when I hit the problem.

VLC is used as a test application to see if the stream can be played back and one that has been validated I know what parameters should be valid to use in Scrypted to get it to work.

Does that make sense?