After updating to the new firmware http://CAMERA_IP/snap.jpg not works anymore. How to get a snapshot now?
5 MegaGixel 1/1.8" low light destroyer for $90-AVOID LONGSE JUNK
- Thread starter klasipca
- Start date
alastairstevenson
Staff member
The problem was that it can be accessed without an authentication. With an additional request they were able to put this snapshot authentication. Now this snapshot feature is disabled at all.
Hi,
I'm going to order one. But it must be possible to get a snapshot from the cam. There is no url where i can get s snapshot with authentication?
I'm going to order one. But it must be possible to get a snapshot from the cam. There is no url where i can get s snapshot with authentication?
SoCal
Young grasshopper
alastairstevenson
Staff member
Just out of interest, I installed the new firmware 3516A_IMX178_W_6.1.25.3 that @klasipca posted.
Interesting about the Hikserver, and the somewhat sparse support for the Hikvision IPDM protocols. Presumably it's a work in progress.
But SADP does see it, and the camera connects OK to a Hikvsion NVR using the Hikvision protocol - though it looks like the resolution is limited to 1280x960
But that's another story ... maybe more later when I've had a look at it.
It would have been better for the /snap.jpg to have been retained with an authentication requirement as opposed to being removed completely.
But for those who want it back, even in an insecure way, here is one way it could be done:
Being an r/w file system - the symbolic link does survive a reboot.
There are other ways - the camera is using the 'boa' webserver. http://www.boa.org/ and a minimal configuration file, but a link is simple and seems to work, as the /dev/snapshot device still exists.
Interesting about the Hikserver, and the somewhat sparse support for the Hikvision IPDM protocols. Presumably it's a work in progress.
But SADP does see it, and the camera connects OK to a Hikvsion NVR using the Hikvision protocol - though it looks like the resolution is limited to 1280x960
But that's another story ... maybe more later when I've had a look at it.
It would have been better for the /snap.jpg to have been retained with an authentication requirement as opposed to being removed completely.
But for those who want it back, even in an insecure way, here is one way it could be done:
Code:
alastair@PC-I5 ~ $ telnet 192.168.1.168
Trying 192.168.1.168...
Connected to 192.168.1.168.
Escape character is '^]'.
(none) login: root
Password:
Welcome to HiLinux.
None of nfsroot found in cmdline.
~ #
~ # cd /opt/app/www
/opt/app/www # ls -al /dev/snap*
-rw-r--r-- 1 root root 518628 Jul 9 10:50 /dev/snap.jpg
crw------- 1 root root 10, 231 Jan 1 1970 /dev/snapshot
/opt/app/www # ln -s /dev/snap.jpg snap.jpg
/opt/app/www #
/opt/app/www # ls -al /dev/snap*
-rw-r--r-- 1 root root 515770 Jul 9 10:53 /dev/snap.jpg
crw------- 1 root root 10, 231 Jan 1 1970 /dev/snapshot
/opt/app/www #Being an r/w file system - the symbolic link does survive a reboot.
There are other ways - the camera is using the 'boa' webserver. http://www.boa.org/ and a minimal configuration file, but a link is simple and seems to work, as the /dev/snapshot device still exists.
Last edited by a moderator:
@alastairstevenson Forgive me if you posted this already, but did you brute-force the telnet root password, or ? I've tried all the usual suspects and can't get access...
<code>
Trying 192.168.0.68...
Connected to 192.168.0.68.
Escape character is '^]'.
(none) login: root
Password:
Login incorrect
(none) login: root
Password:
Login incorrect
(none) login: root
Password:
Login incorrect
(none) login:
</code>
thanx.
<code>
Trying 192.168.0.68...
Connected to 192.168.0.68.
Escape character is '^]'.
(none) login: root
Password:
Login incorrect
(none) login: root
Password:
Login incorrect
(none) login: root
Password:
Login incorrect
(none) login:
</code>
thanx.
Last edited by a moderator:
alastairstevenson
Staff member
I did for some of the other firmware, they are all different (though start with h or hs and relate to the date or version of the firmware), but with this one I cheated.
You need a copy of the firmware file in question, either from the Herospeed.net site, or in this case from @klasipca 's link as this new version is not yet published.
Open the .fls file with your favourite hex editor and search for the passwd file using the text string 'root:'
For the 3516A_IMX178_W_6.1.25.3 firmware it's :
Code:
root:oHf5ap4P4vhJI:0:0::/root:/bin/sh
root:r20QjCLLzTHHY:0:0::/root:/bin/shLHjQopX4yjf1Q for ls123 (l for longse)
Flash the modded firmware on the camera, and you will be in.
From what I can tell (unlike Hikvision) there doesn't seem to be any anti-tamper or integrity (!) protection.
But - be very careful to flash the right firmware for the camera, preferably exactly the same version as it currently has.
There is always some risk doing this.
And for some of the Herospeed firmware major updates, a 2-step 'bridge' process is required for a kernel update as well.
Last edited by a moderator:
Can anyone tell me why, sometimes, with this camera connected to BI, when I play the video back I end up with "trails" on moving objects in the frame. The "trails" clear every second then start again!
Thanks
Rice
Thanks
Rice
fenderman
Staff member
- Mar 9, 2014
- 36,892
- 21,407
An iframe setting of 3(s) on this cam with a frame rate of 20fps means an iframe only every 60 frames,
which is kinda sparse, I think. More frequent iframes (and perhaps less DNR) should help reduce the artifacts...
When configuring iframe interval on these cams, it's labelled as 's' (for 'seconds')
rather than interval like most other cams, so to "match the frame rate and iframe interval"
(as so often recommended here) I set it to 1 (options are only 1-5):
As I understand it, this has the same effect as setting iframe *interval* to 20 on a Hik/Dahua/most-any-other cam with frame rate of 20,
resulting in an iframe every second. In any case, it sounds like he's already got the iframe interval at 1/second,
so DNR is more likely the culprit...
OR, Do i have it backwards and settying iframes to 5 on this cam results in 5 iframes PER second
(not one every 5 seconds?) If so, that might explain a lot about why I'm not as blown away by
these cams as others around here. hahahaha.
which is kinda sparse, I think. More frequent iframes (and perhaps less DNR) should help reduce the artifacts...
When configuring iframe interval on these cams, it's labelled as 's' (for 'seconds')
rather than interval like most other cams, so to "match the frame rate and iframe interval"
(as so often recommended here) I set it to 1 (options are only 1-5):
As I understand it, this has the same effect as setting iframe *interval* to 20 on a Hik/Dahua/most-any-other cam with frame rate of 20,
resulting in an iframe every second. In any case, it sounds like he's already got the iframe interval at 1/second,
so DNR is more likely the culprit...
OR, Do i have it backwards and settying iframes to 5 on this cam results in 5 iframes PER second
(not one every 5 seconds?) If so, that might explain a lot about why I'm not as blown away by
these cams as others around here. hahahaha.
Thanks for the advice. I tried this, but it didn't make much difference. The OSD clock runs slow, then it will skip frames and catch up. It repeats this over about 7-8 seconds.
I'm thinking along the same way as you pozzello, you would think the more often the iframes, the better the motion would be.
DNR is switched off for both 2D and 3D (default setting).
Bit of an update though...
It looks as though my problem could be related to frame rate and bit rate.
So, at 5mp and at 25 fps, what should the bit rate be?
Would variable bit rate not be better than constant?
Rice
Last edited by a moderator:
I've been playing quite a bit with the settings.
DNR is turned off for both 3D and 2D.
It's set to single stream, H264 2592x1944
frame rate from 10 fps up to 25 fps
bit rate from 5000 -> 12000 in steps of 500
Tried both VBR & CBR
The clock running slow, then dropping frames to catch up seems now to be the biggest problem.
I think you and fenderman my have sorted the "trail" issue with the iframe, maybe it is number of iframes / sec, not an iframe every x seconds!
"maybe it is number of iframes / sec, not an iframe every x seconds!"
Now I'm not sure which way this works here.
I played the stream in VLC, (at rtsp://<cam-ip>:554/0 )
which can tell you if frames are being dropped under tools/media-info/statistics.
You were probably having more lost frames before, causing the artifacts (since DNR is off and could not be culprit),
and reducing the frequency of iframes from 5 per sec to 3 per sec would reduce the stream's pre-compression bitrate
such that the cam can deliver more frames without messing up...
if it were the other way around (changed from 1 i-frame every 3 secs instead of every 5,) you'd be increasing
the size of the stream and the cam might have to use more compression to stay under the bitrate limit, so I
would not necessarily expect a better image...
IS there some way VLC can indicate the GOP (iframe interval) ? or some other tool that can display stream stats like that?
Now I'm not sure which way this works here.
I played the stream in VLC, (at rtsp://<cam-ip>:554/0 )
which can tell you if frames are being dropped under tools/media-info/statistics.
You were probably having more lost frames before, causing the artifacts (since DNR is off and could not be culprit),
and reducing the frequency of iframes from 5 per sec to 3 per sec would reduce the stream's pre-compression bitrate
such that the cam can deliver more frames without messing up...
if it were the other way around (changed from 1 i-frame every 3 secs instead of every 5,) you'd be increasing
the size of the stream and the cam might have to use more compression to stay under the bitrate limit, so I
would not necessarily expect a better image...
IS there some way VLC can indicate the GOP (iframe interval) ? or some other tool that can display stream stats like that?
OK, after playing with the iframe setting in the cams UI and watching the resulting stats in VLC,
it's clear that setting iframe to 5s sends an iframe every 5 seconds (regardless of frame rate)
NOT 5 per second as I had hypothesized. The 'content-bitrate' stat spikes every N seconds,
where N is whatever you set the iframe interval to. This is still different from other cams (like Hik & Dahua)
where the interval is how often in frames to send an iframe, not how often in seconds.
it's clear that setting iframe to 5s sends an iframe every 5 seconds (regardless of frame rate)
NOT 5 per second as I had hypothesized. The 'content-bitrate' stat spikes every N seconds,
where N is whatever you set the iframe interval to. This is still different from other cams (like Hik & Dahua)
where the interval is how often in frames to send an iframe, not how often in seconds.
Q™
IPCT Contributor
For the money...and imo...yes, it provides the best night image I've seen in it's price range and it is most definitely worth it.
Some will say I must have got a couple of lemons, but I really think this decent piece of hardware
(big hi-rez sensor, well built tho a bit goofy looking) is crippled by its firmware for use as real 'surveillance' apparatus.
Nice still shots, sure, but for useful records of motion, no better than cheaper, better-supported options.
So, if you can get your perps to stand still while you take their hi-rez snapshots, these are perfect.
(big hi-rez sensor, well built tho a bit goofy looking) is crippled by its firmware for use as real 'surveillance' apparatus.
Nice still shots, sure, but for useful records of motion, no better than cheaper, better-supported options.
So, if you can get your perps to stand still while you take their hi-rez snapshots, these are perfect.