Review - TOP-201 Super Mini 720P HD IP-Cam (The Cheapest IP Cam So Far !!)

[Sparkey]

do the firmware updates make these cameras any more stable? i find blueiris looses the signal of the cameras repeatedly over the course of a day.

I have 5 of them running in Blue Iris and none have ever dropped the connection.

 

[bls]

do the firmware updates make these cameras any more stable? i find blueiris looses the signal of the cameras repeatedly over the course of a day.

And I have 3 of them running in Blue Iris and none have ever dropped the connection.

 

[Zorac]

And I have 3 of them running in Blue Iris and none have ever dropped the connection.

i get just a blip, enough for blueiris to register a lost connection, happens 10 or so times a day. just using the default settings on the camera and in blue iris. any suggestions? bought the cameras in spring and haven't done any firmware updates since.

 

[meesterblack]

To the guys who have/are writing the telnet scripts --- brilliant!

Quick question... has anybody had success with re-naming the onscreen camera name? I can do it through the Chinese CMS interface, but nowhere else that I've found.

I am highly interested in getting my hands on a script that can display updated info to it live -- i.e. temperature, etc, or other data that would be useful. The best part is that encoding such info into part of the streamed image would be transparent to any of NVR software. Sky is the limit! Not sure if there is a character limit.

Thoughts?

 

[jstrom]

I've been running one of the cameras for the better part of the day using VLC, and I must say I'm quite impressed with the image quality (considering the price)! However, another issue came up now. Suddenly, the image had frozen (not sure when; the time was way of on this unconfigured camera). I tried to restart VLC, and it froze after 2 seconds again. The Onvif interface seemed to be able to receive the image though, at least for a while...
I tried a hard reboot of the camera, with no success. Left the power off for a few minutes, still same issue.. Weird! Making it more weird is that I tried VLC on another machine now, and it works perfectly fine.. Odd indeed, but probably not related to the camera then...

A quick update on this. This problem occured the last night again. This led me to believe that it could be light-related, and so it seems. But the biggest part of the fix was to update VLC to a newer version, I noticed it did not hang on my laptop but only on my desktop, which was running an older version of VLC.

But the light-related issue still persist: if i cover up the camera so the picture goes almost totally dark, VLC has issues playing back the video. The actual video either just freezes (timestamp freezes), or in some cases goes gray. The VLC log shows this:

[0000000102827ab8] core video output debug: picture might be displayed late (missing 17 ms)
[0000000102827ab8] core video output warning: picture is too late to be displayed (missing 50 ms)
[0000000102827ab8] core video output warning: picture is too late to be displayed (missing 173 ms)
[0000000102827ab8] core video output warning: picture is too late to be displayed (missing 206 ms)
[0000000102827ab8] core video output warning: picture is too late to be displayed (missing 241 ms)
[000000010fd9f638] core input error: ES_OUT_SET_(GROUP_)PCR is called too late (pts_delay increased to 333 ms)
[000000010fd9f638] core input error: ES_OUT_RESET_PCR called
[000000010fd9f638] core input debug: Buffering 0%
[000000010fd9f638] core input debug: Buffering 13%
[000000010fd9f638] core input debug: Buffering 27%
[00000001021560b8] avcodec decoder debug: available hardware decoder output format 81 (vda_vld)
[00000001021560b8] avcodec decoder debug: available hardware decoder output format 120 (vda)
[00000001021560b8] avcodec decoder debug: available software decoder output format 0 (yuv420p)
[0000000100332068] core generic debug: looking for hw decoder module matching "any": 1 candidates
[0000000100332068] core generic debug: no hw decoder modules matched
[h264 @ 0x1009b6a00] Frame num gap 34 32
[000000010fd9f638] core input debug: Buffering 40%
[h264 @ 0x1009b6a00] no picture
[000000010fd9f638] core input debug: Buffering 54%
[000000010fd9f638] core input debug: Buffering 68%
[000000010fd9f638] core input debug: Buffering 81%
[00000001021560b8] core decoder debug: End of video preroll
[00000001021560b8] core decoder debug: Received first picture
[000000010fd9f638] core input debug: Buffering 95%
[000000010fd9f638] core input debug: Stream buffering done (363 ms in 712 ms)
[000000010fd9f638] core input debug: Decoder wait done in 0 ms
[0000000102827ab8] core video output warning: picture is too late to be displayed (missing 75 ms)

[h264 @ 0x101033600] unknown SEI type 229
[0000000102827ab8] core video output warning: picture is too late to be displayed (missing 108 ms)
[0000000102827ab8] core video output warning: picture is too late to be displayed (missing 143 ms)
[0000000102827ab8] core video output warning: picture is too late to be displayed (missing 211 ms)
[0000000102827ab8] core video output warning: picture is too late to be displayed (missing 206 ms)
[00000001021560b8] avcodec decoder warning: More than 4 late frames, dropping frame
[h264 @ 0x101033600] Frame num gap 13 11
[00000001021560b8] avcodec decoder warning: More than 4 late frames, dropping frame
[h264 @ 0x1010bce00] Frame num gap 15 13
[00000001021560b8] avcodec decoder warning: More than 4 late frames, dropping frame
[h264 @ 0x1009b6a00] Frame num gap 17 15
[00000001021560b8] avcodec decoder warning: More than 4 late frames, dropping frame
[h264 @ 0x101033000] Frame num gap 19 17
[00000001021560b8] avcodec decoder warning: More than 4 late frames, dropping frame

...and so on... until I resume the light conditions, at which time it takes half a second to a few seconds until the image is back and OK.

I tried to change encoding to CBR, no help.
I tried changing the Exposure mode from automatic to a manual setting, and the problem went away immediately. I tried to change the min/max time parameters of the Automatic exposure mode, but did not get any better results.
Setting Day/Night mode to "Black and white" did also fix the issue.
Changing "Image" from "Style2" to "Style3" gave somewhat few issues, but produced a darker image.

If anyone got any other known good ideas to fix this issue, please let us know

 

[jstrom]

Don,

thanks for the ffmpeg tip. Should have done that immediately. It seems VLC has some issues rendering the stream, but ffmpeg outputing to a plain mp4 file does not have the same issues. (I did not use your scripts though, as I'm not on windows).

Camera firmware: V4.02.R12.00006510.10010.1407

I tested by recording the RTSP stream with ffmpeg, and at the same time playing it in VLC and using a screen recorded to capture VLCs behaviour.

The output of ffmpeg version 2.4.3 running with debug logging:
https://gist.github.com/stromnet/e1a10545661041d2e4e8

Screen-capture of the VLC session:

Recorded ffmpeg session:

At frame 161 (ffmpeg output), I'm covering the lens fully with my hand. This seems to produce "** 1 dup!" errors, until I remove my hand.
The VLC playback at this time starts to freeze, the clock stops/image goes semi-gray and very "pixely" until i remove my hand.
Playing back the recorded mp4 file (using same VLC), the image just goes black and the clock ticks on, althoug it skips a few hundred milliseconds it seems (speeds up). Recovers directly when I remove my hand.


So, really two different issues: 1, the camera messes up the video stream a bit when automatic exposure is enabled, and 2, VLC doesn't seem to be very good at handling this (ffmpeg, at least of this version, handling it better).

 

[jstrom]

You are very welcome.

You're on the most current firmware version for the 6510 camera module produced by this manufacturer. So that's good.

If you haven't yet attempted to use the "Reset Utility" provided by this manufacturer for all their camera module hardware versions. Including the 6510. To do a "Hard Reset" on this camera, it's worth a shot to try to see if that may help resolve this issue. The hard reset utility can be downloaded at the link below:

http://www.ipcamtalk.com/showthread.php/1812-Review-TOP-201-Super-Mini-720P-HD-IP-Cam-(The-Cheapest-IP-Cam-So-Far-!!)?p=19499&viewfull=1#post19499

Tried to reset all settings to defaults, didn't help.

I wonder if VLC has any command line/runtime options that would allow it to survive and properly continue when encountering the issues it is? Personally, I don't know. It has been some time since I reviewed the VLC command line/runtime options.

Not sure if this has any part in what's causing your specific issue. But I force TCP to be used with RTSP vs. UDP when using FFmpeg by using this FFmpeg command line option:

-rtsp_transport tcp

I also can't remember if VLC supports forcing TCP for RTSP or not by using a command line/runtime option.

Not sure if you have the luxury to choose what you are using to do RTSP recordings. But if you do, maybe using FFmpeg vs. VLC would be best.

Don

ffmpeg was executed with that parameter, otherwise I have to wait ~10s (at least on VLC) before it gives up on UDP (which is blocked by firewall) and falls back to TCP.
The same setting can be made in VLC, Preferences -> Show all -> Input, Demuxers, RTP -> Use RTP over RTSP (TCP).

However, I think I actually found the VLC issue here! Before I found that force-tcp setting, I tried to lower the buffering latency. In preferences, Input/codecs tab, there is a Default Caching Level which can be set to "Lowest latency". When I changed this back to "Normal", my issues seems to disappear.

As for recording, so far I'm only doing testing, haven't looked into or decided on what to use for recording yet.

 

[sephiro499]

Can you this camera pan or swivel? Right now I use the dlink 930 something VGA ip cameras. Obviously the resolution sucks, but I have them setup inbetween storm windows and i have to be able to pan and tilt it to look out the window.

 

[VorlonFrog]

It has no servo motors of any kind. It does come with a mounting bracket that can be manually positioned as desired.

 

[sephiro499]

So what's a good place to buy: ebay, tinydeal, dealextreme, aliexpress?

 

[VorlonFrog]

Both AliExpress.com and eBay.com provide some measure of buyer protection. Some eBay sellers have stock in the US and ship from the US. But most AliExpress.com sellers ship from China. I've purchased other items from DX with no problems before. Never dealt with tinydeal, though.

 

[sephiro499]

Any trusted ebay sellers. Are knockoffs an issue?

 

[bls]

I have several of the HI3518 boards (marked BLK18E-0012-38X38_S which are model 50H10PE-S & BLK18E-0012_0030-38X38_S which are model 53H13PE-S) that I would like to make use of the I/O Alarm input on in conjunction with the BI (BlueIris). In BI the Make/Model is set to IPC H.264 port 34567 and "Trigger using camera's digital Input or motion" is enabled on the camera setup Motion/Trigger page and have been working with Ken (the BI author) to find out why this feature isn't working for me. Ken said BI looks for Alarm Event Info in the video stream and this has been working with similar cameras, but that there's nothing coming from my cameras but the video stream. The I/O alarm input works fine with the cameras built-in web page which is set up to open up an alarm log screen and play a sound file each time the alarm input is triggered and I'm wondering if anyone knows how to get the camera to also send the alarm event info in the video stream?

After reading that the manufacturers firmware versions were mainly meant to "Show Off" to Network IP Camera builders what their Camera boards could do and that Network IP Camera builders were expected to provide their own custom firmware (in msg http://www.ipcamtalk.com/showthread.php/1812-Review-TOP-201-Super-Mini-720P-HD-IP-Cam-(The-Cheapest-IP-Cam-So-Far-!!)?p=39887&viewfull=1#post39887 ) I'm wondering if the boards Ken saw work were perhapes boards with custom firmware in cameras from a Camera builder which had added the Alarm Event Info in the video stream where as my boards have a manufacturers firmware version that doesn't (mine have V4.02.R12.00006510.10010.1303).

Anyway, I keep seeing messages in this thread from those knowing much more than I ever will and who have discovered undocumented ports and various other ways of extracting info from these cameras and wondering if anyone has come accross a way to receive alarm info from these cameras with a manufacturers firmware version.

Barry

 

[VorlonFrog]

The .1303 suffix at the end of your firmware is an older build. It's possible the later .1403 and .1407 builds might work better for you.

 

[sephiro499]

You can buy it for around 17 on the BIC website with free shipping or buy it on ebay for 5 dollars more??? Since the site accepts paypal I don't see the point of buying it on ebay.

 

[Nenad Milovanovic]

Hi,

Do you have some recommendation for camera like this, but with WiFi?

 

[bls]

I have several of the HI3518 boards (marked BLK18E-0012-38X38_S which are model 50H10PE-S & BLK18E-0012_0030-38X38_S which are model 53H13PE-S) that I would like to make use of the I/O Alarm input on in conjunction with the BI (BlueIris). In BI the Make/Model is set to IPC H.264 port 34567 and "Trigger using camera's digital Input or motion" is enabled on the camera setup Motion/Trigger page and have been working with Ken (the BI author) to find out why this feature isn't working for me. Ken said BI looks for Alarm Event Info in the video stream and this has been working with similar cameras, but that there's nothing coming from my cameras but the video stream. The I/O alarm input works fine with the cameras built-in web page which is set up to open up an alarm log screen and play a sound file each time the alarm input is triggered and I'm wondering if anyone knows how to get the camera to also send the alarm event info in the video stream?

Problem Solved! I can't say enough about Ken, the author of BI. He found the "secret command" necessary to start the alarm info flowing and the "Trigger using camera's digital input or motion" option was expanded and now works for cameras that use port 34567 including IPC, IPCX, & CantonK models (after BI update 4.1.4).

The .1303 suffix at the end of your firmware is an older build. It's possible the later .1403 and .1407 builds might work better for you.

I realized that 2 newer versions were available, but 1303 wasn't that old (Jan 2015) and, unlike some that can't resist updating firmware the minute a new version is available, I was reluctant in case a newer version may introduce other issues (like a number found when updating to version 1407 which removes the ability to use the usb port for a wi-fi board) and I didn't want to risk loosing the ability to use the audio port like I did after updating the firmware on one of my other cameras. Anyway, when it comes to updates I've found it's usually best to leave things alone unless one is having a problem that an update is known to correct (in other words "If it ain't broke, don't fix it").

 

[VorlonFrog]

Problem Solved! I can't say enough about Ken, the author of BI. He found the "secret command" necessary to start the alarm info flowing and the "Trigger using camera's digital input or motion" option was expanded and now works for cameras that use port 34567 including IPC, IPCX, & CantonK models (after BI update 4.1.4).

Can you elaborate on where/how to expand the Trigger option?

I realized that 2 newer versions were available, but 1303 wasn't that old (Jan 2015) and, unlike some that can't resist updating firmware the minute a new version is available, I was reluctant in case a newer version may introduce other issues (like a number found when updating to version 1407 which removes the ability to use the usb port for a wi-fi board) and I didn't want to risk loosing the ability to use the audio port like I did after updating the firmware on one of my other cameras. Anyway, when it comes to updates I've found it's usually best to leave things alone unless one is having a problem that an update is known to correct (in other words "If it ain't broke, don't fix it").

Oh, I agree with you, don't update the firmware unless it's absolutely necessary. Hence my original statement including the words "possible" and "might". Really glad to hear you were able to get it working!

 

[bls]

Can you elaborate on where/how to expand the Trigger option?

Oh, I agree with you, don't update the firmware unless it's absolutely necessary. Hence my original statement including the words "possible" and "might". Really glad to hear you were able to get it working!

I'm assuming you mean where/how to expand the Trigger option on the camera pcb and, while there's been some info on this thread previously about the p5 8-pin connector on the camera board and which pin is the alarm I/O input, I have details about how I connected to the alarm input at http://ve6sbs.sbszoo.com/projects/ipcam_ipc/50H10PE-S/50H10PE_mods.htm and there's a link next to the first image to a PDF with a wiring diagram. Disregard any referance to the camera IP as the PDF is my personal record of mods made to the camera and the IP is simply the IP used for the camera on my LAN. And now that BI works with the alarm input I plan to update the page with how the input was used with a passive IR/Microwave motion detector once I am finished doing that so check the page again in a few weeks. And there's links to similar IP camera mod's on http://ve6sbs.sbszoo.com/ in case you're interested.

And I debated as to whether to reply to your previous message and say anything about updates, but I'm amazed how many can't resist updating to the latest version for no real reason after all that's been said cautioning against this and who then end up with problems and I figured one more warning wouldn't hurt.

 

[The_Penguin]

http://ve6sbs.sbszoo.com/projects/ipcam_ipc/ipc_mods.htm and there's a link next to the first image to a PDF with a wiring diagram..

Greetings from another VE6 Great web site and info. Thanks for sharing!