How to access the video streams of a camera or NVR?

[aster1x]

I actually have all my cameras on PnP (out of laziness really) and haven't had the gateway overwritten by the NVR even after multiple reboots of the NVR/Camera/Both. Though I agree that manual would be the safest bet to ensure everything is working 100%.



That's interesting, I can open up the camera stream the exact same way that alastairstevenson did using rtsp://192.168.254.X:554. So just to clarify, you're saying you cannot access rtsp://192.168.254.X:554 (the stream) but you can access the camera web interface using http://192.168.254.X:80?

Have you checked that your RTSP on the camera is actually 554? I've seen some cases where it was set to 10544 for some reason. Otherwise, maybe it could be your router? You could rule that out by connecting your computer directly to one of the camera ports, changing your computer ip to 192.168.254.128 and trying to open the stream at rtsp://192.168.254.X:554. Those two points considered, it may actually be that Hikvision changed their implementation of Virtual-Host between firmwares and that your version actually doesn't bridge the 554 port.

You understood me correct. I can access the camera web interface using http://192.168.254.2 but I can not access the videostream using rtsp://192.168.254.2:65001 or rtsp://192.168.254.2:65001/Streaming/Channels/101 from the browser or VLC.

Also my camera rtsp is 65001 and not 554. I believe it should be 65001 in order for the virtual host to operate. Do you imply that rtsp works only through port 554 and not 65001?
I will try later your suggestion to connect the computer directly to the camera ports of the NVR.

 

[aster1x]

The Linux kernel IP routing capability is at a lower level than RTSP or HTTP so should not be port selective.
However I have wondered how the Virtual Host is implemented (I don't have an NVR with it that I could investigate) - is it a simple NAT arrangement, or something more capable like a proxy? Either would fulfil the requirement to masquerade the native camera address while providing access from the NVR LAN segment, avoiding the need for the user to change their network capability. @aster1x - do you have a telnet feature on your NVR that gives access to a command prompt (not the 'psh' shell)?
If so - check the result of this command:

Yes I have telnet feature and the ip_forward is 1.

 

[alastairstevenson]

I believe it should be 65001 in order for the virtual host to operate.

No, you don't need to change the RTSP port from its normal 554 in order for Virtual Host to operate.
Just as an experiment, via the camera web GUI can you set the RTSP port back to 554 on the camera you've been testing, reboot it, and try again with VLC to connect to the camera with rtsp://192.168.254.2:554/Streaming/Channels/101

 

[aster1x]

Well done and thank you Alastair and DemonicHawk for your guidance and suggestions. I changed the camera rtsp port to 554 and now I can access both video streams (high and low res) with VLC using rtsp://192.168.254.2:554/Streaming/Channels/101 (and 102). The camera web interface is still accessible as before using http://192.168.254.2 OR http://192.168.1.NVRIP:65001 which has not been changed.
Problem solved.

 

[aster1x]

Is it possible to view jpeg or mjpeg streams from this camera?

 

[alastairstevenson]

Excellent! Well done for doing the tests and sharing the results.
It seems to me that this forum is on a bit of a roll over the last few weeks - lots of interesting new stuff, lots of sharing and helping and commenting, things learned and shared and problems solved.
It's all good!

 

[aster1x]

I totally agree with you Alastair. However, this topic of accessing streams was discussed again last year sometime but I could not find the relevant posts. What this forum is missing is someone to make a summary of the most important solutions found. I see a lot of people who struggle with the networking configuration of the cameras, the NVRs and the routers. However the steps for configuring are not infinite. The problems solved wioth the virtual host have been documented by me, you and others but still we do not have a summary of our conclusions as a sticky. The worst is the combination of firmwares, models and region compatibilities. I wish somebody could create a sticky of somw of these things or even better a WIKI. We all have contributed, and we all keep answering the same questions again and again. Can the moderators take the initiative to have stickies or a WIKI?

 

[alastairstevenson]

You are quite right - many's the time I have a recollection of something being discussed and try a search for it - but can I find it - no way. Keyword tagging might help, but would depend a lot on the contributors for accuracy and relevance.
A Wiki would be good and probably best - but I suspect it would be a lot of work, even with a shared effort.
Stickies are good - but realistically are limited in the number before they dominate a thread.
Let's see what the mods suggest ...

 

[bve]

I know this is an old thread, however I wanted to add my thanks too.

In my case my setup is a Trendnet TV-NVR208 (8 channel POE NVR) of course the documentation for this device is very poor & incorrect... documentation actually states using rtsp://CAMERA-IP-ADDRESS:554/Streaming/Channels/01 with only 2 digits, however as you know the cams would be on a different subnet than the rest of the LAN, so I knew that was incorrect. It also has virtual host configuration which was fruitless using the suggested virtual port. Either way in my case I wanted to use the streams to also record to my Linux box using this great script Record and archive video from IP cameras | LucaTNT's which is all I was using prior to buying the NVR.

Thanks again,
Burke

I just found out how to do it.

Basically for VLC its:

rtsp://NVR-IP-ADDRESS/Streaming/Channels/101

The 101 at the end means:

x01 - where x equals channel number
1xx - where xx equals 01 is Main Stream and 02 is Substream

e.g.

rtsp://192.168.0.253/Streaming/Channels/101 - Channel 1 Main Stream


^Beat me to it. With VLC you don't need to put the username and password in the URL, (I probably would prefer not to, cause you can see the password in the URL.) However, it does make it easier and quicker to open the stream.