Jump to content

mroek

Members
  • Content Count

    150
  • Joined

  • Last visited

Everything posted by mroek

  1. I have now spent some time tinkering with the cameras, and I have found a way to modify (and delete) the accounts even if the web interface does not allow that. The camera config is stored in two locations: /mnt/backup/Config /mnt/mtd/Config The backup location appears to be just that, a backup of the config. The config that is actually used is the latter, but files will be copied to the backup folder automatically. The accounts are stored in this file: /mnt/mtd/Config/Account1 Unfortunately, Dahua has not included any text editor (not even vi, can you believe it), so to edit the file you need to have a FTP server in your network, and then use ftpput to copy the file to the FTP, modify it on your computer, and ftpget it back onto the camera. The account file is clear text, and easy to read. This is how it looks by default (serial number has been edited by me): // ÄÈϾÄÕʧÅäÖãÄÈϾÄ×é°üº×éÃûºÍ×éÃèÊö¾È¹ØÌîÏî£ÄÈϾÄÓç°üºÓçÃû£Óç // ÃèÊö£ËùÊô×éÃû£ÃÜÂë£ÊÇ¡ñš²Ïí¾È¹ØÌîÏdefaultÓç²ÓÃдÔÚϹíÖÐ¥£ { "DevInformation" : { "SerialID" : "TZC2Lxxxxxxxxx" }, "Groups" : [ { "AuthorityList" : [ "ShutDown", "Monitor_01", "Replay_01", "Record", "Backup", "MHardisk", "Account", "Alarm", "QueryLog", "DelLog", "SysUpdate", "AutoMaintain", "GeneralConf", "EncodeConf", "RecordConf", "ComConf", "NetConf", "AlarmConf", "VideoConfig", "DefaultConfig", "VideoInputConfig" ], "Id" : 1, "Memo" : "administrator group", "Name" : "admin" }, { "AuthorityList" : [ "Monitor_01", "Replay_01" ], "Id" : 2, "Memo" : "user group", "Name" : "user" } ], "Users" : [ { "AuthorityList" : [ "ShutDown", "Monitor_01", "Replay_01", "Record", "Backup", "MHardisk", "Account", "Alarm", "QueryLog", "DelLog", "SysUpdate", "AutoMaintain", "GeneralConf", "EncodeConf", "RecordConf", "ComConf", "NetConf", "AlarmConf", "VideoConfig", "DefaultConfig", "VideoInputConfig" ], "Group" : "admin", "Id" : 1, "Memo" : "admin 's account", "Name" : "admin", "Password" : "6EFF35CB0D61578D8D0A5351CA74ADB5", "Reserved" : true, "Sharable" : true }, { "AuthorityList" : [ "ShutDown", "Monitor_01", "Replay_01", "Record", "Backup", "MHardisk", "Account", "Alarm", "QueryLog", "DelLog", "SysUpdate", "AutoMaintain", "GeneralConf", "EncodeConf", "RecordConf", "ComConf", "NetConf", "AlarmConf", "VideoConfig", "DefaultConfig", "VideoInputConfig" ], "Group" : "admin", "Id" : 2, "Memo" : "888888 's account", "Name" : "888888", "Password" : "261E49200CB8EA1800A9568504FBA0C3", "Reserved" : true, "Sharable" : true }, { "AuthorityList" : [ "Monitor_01", "Replay_01" ], "Group" : "user", "Id" : 3, "Memo" : "666666 's account", "Name" : "666666", "Password" : "A36040975B36C11630E534AB561D77AD", "Reserved" : true, "Sharable" : true }, { "AuthorityList" : [ "Monitor_01" ], "Group" : "user", "Id" : 4, "Memo" : "default account", "Name" : "default", "Password" : "B1AF93D7B8D1C96E4563AB36095687FA", "Sharable" : true } ] } As you can see, there are four users defined: admin, 888888, 666666 and default. If you just want to be able to delete the users from within the camera web interface, change the "Reserved"-property from true to false. Then, after putting the file back onto the camera, reboot (just use the reboot command from the shell) it to make the changes effective. After the camera has rebooted, you can now do what you want with the accounts. A word of caution, though: I have only tried deleting one of the extra accounts, so I don't know for sure if renaming/deleting the admin account will have any adverse effects (clearly you must retain at least one account with full admin privileges), but I believe it should work just fine. Don't try to edit the passwords manually, they are just hashes (and also salted, I think), only change them from the web interface. This is just for information, I'm not responsible for anything you might do! I'm not including detailed instructions here, because those that would want to do this already have the required knowledge.
  2. Interesting.. Thanks to you, I found a new firmware for my Dahua 2100.. Actual : Device Type IPC-HFW2100 (PAL) Software Version 2.100.0001.0.R, build : 2012-10-31 WEB Version 3.0.0.0 There : General_IPC-HX2XXX_Eng_P_BootSpi_V2.100.0001.0.R.20121031.bin The name doesn't specify if it's a PAL version, but the website is a Spanish one, so a European. It should be a PAL one, isn't it ? Anyway, I'm a little bit afraid of upgrading it... I don't want a brick... First: The Spanish site firmware for the HFW2100 is an older version: General_IPC-HX2XXX_Eng_P_V2.100.0000.8.R.20120523.bin. Please note the difference between HFW and HDW, where the latter is the dome version, and the former is the bullet. The version you found is for the HDW-version, and it has the same version number as you already have on your camera. The latest released version for your camera is the one you already have, which is: 2.100.0001.0.R, build : 2012-10-31 In other words: Don't flash your camera with anything from the Spanish site.
  3. I wrote a separate post about lens(es) bought from Anykeeper: viewtopic.php?f=19&t=34667 I bought several lenses, but I have only tested the 3.6 mm version, which fitted without issues, and which actually had quite a bit wider view than the factory installed 3.6 mm lens.
  4. One of my Dahua bullets (HFW2100) has similar (but on mine they are blurry) vertical lines, but they are only visible when the ambient light is very low (and thus gain is high). I've chosen to just ignore it, it's not bad enough to warrant an exchange.
  5. That's not possible. The rear lens element is located, you guessed it, at the rear. Cutting would just render the lens unuseable.
  6. Today one of my cameras stayed in the noise reduction mode even after there was normal daylight outside. This is really annoying, and I strongly feel that Dahua should give us a switch to turn off this noise reduction, or at least dial it down. Even at night, I don't mind some noise in the images, it is still way better than the smeared low-detail image that their noise reduction creates. Moving the gain slider a notch and then back will turn off the noise reduction (but only temporarily, of course), but it really shouldn't be necessary.
  7. Same firmware as me, then. Yes, it is kind of random, which makes it even more irritating. Another thing I'd like to have more control over is how quickly the camera adjusts exposure. I am getting a number of false motion detection alerts because the camera has a tendency to adjust exposure and/or gain a bit too much up and down, especially at dusk and at dawn, when the sun is rising or setting. Had the camera adjusted more slowly, I'd have gotten fewer alerts.
  8. Just one more update from me on this: I studied this a bit more yesterday, and I have come to the conclusion that the issue is probably caused by an overly aggressive noise reduction algorithm. Noise reduction is known to also kill details, so that makes perfect sense. The problem here is that we have no manual control of this algorithm. It would have been nice to be able to adjust the parameters for this algorithm.
  9. Which firmware do you have on those cameras? If it is an older version, it means they (Dahua) haven't been able to (or tried) to fix it either, even though I am certain that it actually is a quite simple thing to fix.
  10. And now I have actually found a way to get the camera into this state. The same thing happens on my other cameras as well, so there is no doubt that it is a firmware bug. To get the camera into this state, all it takes is to go to the "Conditions" tab, and change exposure mode to manual and 1/10000. What happens then is that the video feed first goes black (due to the short exposure time), but slowly the gain is boosted until the image has a normal brightness, but with a lot more noise, of course. A few seconds after the gain adjustment has finished, the camera suddenly enters the "low detail, low saturation mode". Setting the exposure mode back to normal fixes it. I made a screencap-video of the process here: At 09:30:26 (on the clock in the actual video) the transition to "crap"-mode happens, approximately 7 seconds after the automatic gain adjustment process has stabilized. The video window is of course so small that the loss of detail is a bit difficult to see, but the drop in saturation is easy to see, so you'd just have to believe me that details are also lost. In real life, this could also happen if the camera is in low light (and gain is boosted), and a light source (car headlamp/flashlight) shines into the camera momentarily.
  11. Turns out that I actually caught the transition into this state on a recording. What happened was that the headlights of a neighbor's car shone into the camera, and a few seconds afterwards, the camera suddenly switches to the "low detail"-mode. Not a shadow of a doubt in my mind that it is a firmware bug.
  12. This morning the camera was back in this state (yesterday I changed the video settings to VBR and a target bit rate of 4096, just to see if that had anything to do with it). What I noticed (from the live tab in the camera web interface), was that the reported bit rate was around 1700 kbps. Resolution was showed as 1280*960. What I did then was to change the bit rate to CBR (still 4096). The actual bit rate then jumped to the expected 4000-4100 kbps, but the image quality remained the same, i.e smeared details and slightly low color saturation. I tried changing bit rate (and mode) back and forth a few times, but while the actual bit rate changed, the image quality was still bad. Then I tried briefly changing exposure mode to manual and then back to auto. To my surprise, that "fixed" it, and the image quality was back to normal. What this shows is that the error (when present) has already been introduced before the video encoder, so the noise theory goes down the drain. This is indeed a strange issue, but I am quite convinced that it is a firmware bug, not something physical wrong with my camera. I have now seen it three times, the first time it fixed itself (which I believe it will probably always do, eventually).
  13. There really isn't that much difference in effective resolution in the 50 vs 20 gain images, but the latter is of course much darker. To show you what I mean, attached is a 100% crop from each of your images, but I have adjusted the darkest one (gain 20) in Photoshop so that it matches the overall color and luminosity of the high gain original. As you can see, there is a bit more resolution in that image, but it isn't a whole lot.
  14. Regarding port 9988 being used in a test version, that's probably correct, but my cameras are not running a test version, they have the latest available release, which is: 2.100.0001.0.R, build : 2012-10-31. I am aware that Dahua has moved the Onvif-functionality to the web port (80) instead, but they haven't released a firmware for this model (yet) which has this change implemented. There are newer test versions for this camera, sure, but I don't have access to any of those. There is a difference in effective resolution (due to the compression artifacts), but the number of pixels in the images are the same. Anyway, as GMaster1 has demonstrated, this is normal behaviour for these cameras in low light if the gain is allowed to go too high. I'm not sure I want to lower the gain, because then the images become quite dark.
  15. Surveillance Station connects to the camera using Onvif (port 9988), and it does get the main stream, not the sub stream. To reiterate: The live view was exactly the same, both in the camera web interface and in other software (LiveVue), so this has nothing to do with Surveillance Station.
  16. The images were captured from recordings made by Synology Surveillance Station, but I am certain that has nothing to do with it. As mentioned, the live stream was identical, no matter how I viewed it (camera web interface/rtsp/tcp 37777). I am leaning towards Korgoth's explanation about image noise causing the h264 encoder to saturate the bandwidth, and thus dropping detail. Currently it is dark outside, and the camera has compensated by upping the gain quite a bit, and this causes a lot more noise, which in turn makes life difficult for the encoder. I am seeing much of the same now that I did in the posted captures, and I am going to watch closely tomorrow morning as it gets lighter outside.
  17. Not likely, I think. I also have recordings with moving people in them, and they look normal except for the fact that everything is blurred/less detailed. The live view was also the same.
  18. Aha, then I understand what you mean. However, if that was the case with this specific image/scene the same problem should have been present even after a reboot.
  19. I have found a workaround for this. If you visit the "Overlay" tab in the on the "Setup/Camera/Video", the image will be updated, and should be correct when you return to the event mask setup page.
  20. Not sure I understand why that would be so, given that CBR is "constant", so whatever is encoded there should not be any more or less data to push. I'm not questioning your real life experience, it's just that I don't understand the reason why it would be so. I've now tried changing from CBR to VBR (at "best" image quality), and for a static image the bitrate seems to be more or less exactly the same, around 4000 kb/s. I'd have expected the actual bit rate to drop quite a bit, but it doesn't. Image quality also seems to be pretty much identical.
  21. No, I haven't. I've always thought that CBR would be the way to go.
  22. I'm having the same issue, but I don't really think there is a way to fix that, unfortunately. A new firmware could of course fix it, but Dahua has a stupid policy on firmware updates (and how they make them available). Another issue that is annoying, is that in the twilight period, the camera adjusts gain or exposure up and down, as if they forgot to add some hysteresis to their algorithms. These rather rapid adjustments triggers motion detection on my NAS (Synology), and that's irritating.
  23. Just a quick question: The default setting of my Dahua cameras is to automatically reboot each night at 02:00. I find this a bit odd for several reasons, one is that Linux is normally considered pretty stable (I never reboot my Linux-based Netgear router), and the other is that most embedded devices has a watchdog to take care of rebooting when things go haywire. So, why does Dahua think that their cameras should have reboot every day? Is that really necessary, or is it them just being overly cautious? Has any of you tried disabling this auto reboot, and if so, did the camera crash or otherwise become inaccessible at some point?
  24. Then I don't have any ideas what could be causing it. On my cameras (different model than yours) it works as expected. One last thing to try, is to reset the camera to factory settings (using the physical reset button), and see if that changes anything.
  25. Does the live view from the camera work (if you press the Live tab)?
×