I've been trying to get some of my low end DLink cameras to work with XProtect Go. I have been successful getting their feeds in iSpy, BlueIris, VLC, and the D-ViewCam. However, for some reason I could not get them to work with XProtect.
After trying many different settings, and searching the web for hours, I finally decided to try Wireshark. I am no expert with wireshark by any means, but it seemed to me that XProtect was failing to add the correct port to the request URL even though I had specified a port when setting up the camera. So I tried setting the port back to port 80 on the camera itself, but it seemed to have no effect.
In XProtect I have tried many combinations, and during the wireshark test was trying (turns out it does work):
Code: JPEG
Streaming Mode: HTTP
Delivery Mode: Multipart stream
Retrieval mode: Snapshot
Connection URI: mjpeg.cgi
I realise these are two different IPs, I was capturing data using two different cameras to make it easier to filter through the results in Wireshark. However, all the cameras work with BlueIris. (Yes I changed IPs and passwords for this post)
XPROTECT (Doesn't Work):
GET /mjpeg.cgi HTTP/1.1\r\n
User-Agent: HTTP Image Reader\r\n
Connection: Keep-Alive\r\n
User-Agent: HTTP Image Reader\r\n
Authorization: Basic YWRtaW46==\r\n
Credentials: admin:password
Full request URI: http://192.168.1.17/mjpeg.cgi
BLUEIRIS (Works):
GET /mjpeg.cgi HTTP/1.1\r\n
User-Agent: BlueIris\r\n
Connection: Keep-Alive\r\n
Authorization: Basic YWRtaW=\r\n
Credentials: admin:password
Full request URI: http://192.168.1.18:818/mjpeg.cgi
Solution
After doing more research on the web and pouring over other people's posts with the same problem I finally found the solution.
It turns out there are quite a few settings that actually do work with XProtect. However, XProtect does seem to have a flaw in that it cannot correctly pass authentication to the DLink camera.
The biggest change I needed to make was turning off UAC as this post suggested. It is found on the Maintenance tab of the DCS-930L and DCS-932L cameras under Server Settings, it is called User Access Control. By disabling this feature I believe you are turning off the ability to have multiple user accounts on the camera itself, a nice feature being lost, but in my case I can live without it.
Once that change has been made on the camera, specific ports do seem to work just fine. Specific ports are nice if you want direct access to the cameras through your firewall, in my case so the DLink mobile app doesn't time out.
The Settings in XProtect that I have found to work the best are:
Codec: JPEG
Streaming mode: HTTP
Delivery mode: Non multipart stream
keep alive type: Default (greyed out)
Retrieval mode: Snapshot
Connection URI: image/jpeg.cgi
These settings seem to provide a more consistent network stream when viewed in wireshark:
Codec: JPEG
Streaming mode: HTTP
Delivery mode: Non multipart stream
keep alive type: Default (greyed out)
Retrieval mode: Streaming
Connection URI: video.cgi
Other delivery modes, retrieval modes, and URI's do work, however the ones I tried caused a great deal of jerkiness to be introduced into the stream.
Notes
Edit: I am using the Universal 1 channel driver in XProtect. Also, DCS-932L and 930L cameras are NOT ONVIF compatible , nor do they support RTSP streams. If you want the technical details on how to use the XProtect universal driver you can find them in their KB article 197.
Edit2: I ran into an issue where the cameras were flashing, or not connecting at all in the smart client. I had to disable the microphone on the server side to fix this issue. I have not configured it yet, perhaps when correctly configured it will not be an issue.
Edit3: I have noticed that when the microphone is enabled that the video stream slows up quite a bit, but if I use the jpeg snapshots refresh speed is still quite good. The downside is that the snapshots take up easily 3 times the space and bandwidth.
Streaming Mode: HTTP
Delivery Mode: Multipart stream
Retrieval mode: Snapshot
Connection URI: mjpeg.cgi
I realise these are two different IPs, I was capturing data using two different cameras to make it easier to filter through the results in Wireshark. However, all the cameras work with BlueIris. (Yes I changed IPs and passwords for this post)
XPROTECT (Doesn't Work):
GET /mjpeg.cgi HTTP/1.1\r\n
User-Agent: HTTP Image Reader\r\n
Connection: Keep-Alive\r\n
User-Agent: HTTP Image Reader\r\n
Authorization: Basic YWRtaW46==\r\n
Credentials: admin:password
Full request URI: http://192.168.1.17/mjpeg.cgi
BLUEIRIS (Works):
GET /mjpeg.cgi HTTP/1.1\r\n
User-Agent: BlueIris\r\n
Connection: Keep-Alive\r\n
Authorization: Basic YWRtaW=\r\n
Credentials: admin:password
Full request URI: http://192.168.1.18:818/mjpeg.cgi
Solution
After doing more research on the web and pouring over other people's posts with the same problem I finally found the solution.
It turns out there are quite a few settings that actually do work with XProtect. However, XProtect does seem to have a flaw in that it cannot correctly pass authentication to the DLink camera.
The biggest change I needed to make was turning off UAC as this post suggested. It is found on the Maintenance tab of the DCS-930L and DCS-932L cameras under Server Settings, it is called User Access Control. By disabling this feature I believe you are turning off the ability to have multiple user accounts on the camera itself, a nice feature being lost, but in my case I can live without it.
Once that change has been made on the camera, specific ports do seem to work just fine. Specific ports are nice if you want direct access to the cameras through your firewall, in my case so the DLink mobile app doesn't time out.
The Settings in XProtect that I have found to work the best are:
Codec: JPEG
Streaming mode: HTTP
Delivery mode: Non multipart stream
keep alive type: Default (greyed out)
Retrieval mode: Snapshot
Connection URI: image/jpeg.cgi
These settings seem to provide a more consistent network stream when viewed in wireshark:
Codec: JPEG
Streaming mode: HTTP
Delivery mode: Non multipart stream
keep alive type: Default (greyed out)
Retrieval mode: Streaming
Connection URI: video.cgi
Other delivery modes, retrieval modes, and URI's do work, however the ones I tried caused a great deal of jerkiness to be introduced into the stream.
Notes
Edit: I am using the Universal 1 channel driver in XProtect. Also, DCS-932L and 930L cameras are NOT ONVIF compatible , nor do they support RTSP streams. If you want the technical details on how to use the XProtect universal driver you can find them in their KB article 197.
Edit2: I ran into an issue where the cameras were flashing, or not connecting at all in the smart client. I had to disable the microphone on the server side to fix this issue. I have not configured it yet, perhaps when correctly configured it will not be an issue.
Edit3: I have noticed that when the microphone is enabled that the video stream slows up quite a bit, but if I use the jpeg snapshots refresh speed is still quite good. The downside is that the snapshots take up easily 3 times the space and bandwidth.
8 comments:
Thanks for the post. Were you able to get audio working?
Unfortunately no I haven't. I haven't had time to mess with it a lot since this post.
Check out IP Camera Viewer. It is free ip camera software that will view up to 4 cameras on one screen. It has support for over 2200 different IP camera models.
It looks like a very nice piece of software, but it does not appear that they offer a mobile app for remote viewing. I also believe that their video playback and search features will be significantly inferior to XProtects. However, it looks like a great piece of software to start out with and see if it will fit your needs.
Just wanted to say thanks - found this when trying to troubleshoot my first camera install with XProtect. Appreciate your taking the time to document this!
I'm glad I was able to help. I have since moved away from wireless cameras for security reasons. These D-Link cameras in particular are really bad for anything other than an entry level camera due to quality, price, and video compression.
It is almost 2024 and this post is still relevant !
Thank you for keeping this page and information up for so many years 🤩
Post a Comment