Posts Tagged ‘camera’
Network Cameras and Video Servers
An example to give an idea of how robust and reliable network cameras and video servers today are. Fl***h made video encoder hardware.
The request is http://***.***.***.***/cgi-bin/***.cgi?***, it informs on capabilities of the device.
...
SupportDigitalOutputCount=4
SupportDigitalIutputCount=4
...
Subscribe to the comments for this postIQeye camera video quality
That was a good one. Quality setting UI title vs. internal identifier on an IQeye705 camera:
- “superfine” = xlow
- “fine” = low
- “high” = medium
- “medium” = high
Mobotix cameras online (updated)
Mobotix cameras online, various models discovered by web spider bot, see previous list here:
Basic
- , http://85.47.147.28 - Firmware M1-V1.9.4.8 (2003-12-01)
D10D-Secure
- M10-1-38-123, http://mbsj.no-ip.org:7001 - Firmware M10-V2.1.0.9-D10 (2005-01-07)
D12D-Sec
- D12, http://cabanga.dvrdns.org:8080 - Firmware MX-V3.4.2.2 (2008-04-25)
Y-Cam Black camera
A customer complained that he was unable to get things working with Y-Cam Black camera. Naming models using colors is already a sign that problems are inevitable. The camera either had old firmware and implemented a different protocol (other than documented) or the documentation sucked but I would like to mention a different thing.
I was impressed that the camera did not accept HTTP authentication from FireFox. Sure it claims to be RFC 2616 (Hypertext Transfer Protocol — HTTP/1.1) compliant, it would get insulted being suspected in not abiding it by, but still the fact: open camera URL from Internet Explorer and you get authorized after a propmt for a password and a valid entry. Open it using FireFox and you will be kept prompted for the password infinitely. No firmware updates available free, one should be requested by email. People are seriously releasing and selling such a crappy stuff.
There is a demo camera, a different model however (White) http://guest:guest@y-cam.dtdns.net:8152/, it is free from this issue.
I am whining about software/firmware only, if you need a comprehensive review on the camera, you can find it on networkwebcams.co.uk/blog.
TRENDnet Cameras Online
Found at http://trendnet.com/demo/
- TRENDnet TV-IP422W Wireless Internet Camera Server http://guest:guest@65.44.139.2:9189
- TRENDnet TV-IP301W Wireless Advanced Day/Night Internet Camera Server w/ Audio http://guest:guest@65.44.139.2:9211
- TRENDnet TV-IP201W Wireless Internet Camera Server w/ Audio http://guest:guest@65.44.139.2:9212
- TRENDnet TV-IP110W Wireless Internet Camera Server http://guest:guest@65.44.139.2:9213
- TRENDnet TV-IP212W Wireless Internet Camera Server w/ 2-Way Audio http://guest:guest@65.44.139.2:9214
- TRENDnet TV-IP312W Wireless Day/Night Internet Camera Server w/ 2-Way Audio http://guest:guest@65.44.139.2:9215
- TRENDnet TV-IP400W Wireless Advanced Pan/Tilt Internet Camera Server http://guest:guest@65.44.139.2:9222
One more time TRENDnet guys proved they can screw any great idea. M-JPEG content sent by TV-IP422W cameras has no indication of proper MIME type. We can survive this, thanks blokes you are at least giving Content-Length value! The major problem is that IJG decoder stumbles with exception on the JPEGs: each frame is prepended by 28 byte informational header (hopefully - I will have to look into the source code to find out) messing video decoder. I hope in future TRENDnet devs will discover APPn JPEG markers or multipart/mixed content-type subheaders and find it more approprioate to put this information into these cozy places.
TV-IP301W just has a typo in multipart/mixed header:
GET /goform/video3 HTTP/1.0
User-Agent:
Authorization: Basic Z3Vlc3Q6Z3Vlc3Q=
Connection: Keep-AliveContent-Type: multipart/mixed;boundry=cellvision
–cellvisionContent-Type: image/mpeg
HTTP/1.1 200 OK
OMG!!! Response line goes after Content-Type header… There is just nothing to say about this.
By “image/mpeg” (I have not found it in MIME type reference) they mean server-pushed stream of JPEG images, by the way.
BUT! These new models TV-IP212/TV-IP212W/TV-IP312/TV-IP312W/TV-IP422/TV-IP422W are much much better than older on the product line and they are still not expensive. I believe they are going to be very popular.
See also:
More about APIs
Just recently there was a problem discovered in considered to be stable DirectShow component (the problem itself is not fatal - access violation while being used in improbable scenario - and thus it may appear it is even ignored), another “pleasant” thing came up with an API from another vendor.
The camera vendor is recognized in the industry and even considered to be among leaders, kind of “cheap for superior quality”. Their SDK/API has always been offered to reach several goals: the first was to cover product line with unified access method; the second was to embed implementation of a not so much popular TFTP protocol used for this type of hardware (rivals use more popular protocols: HTTP, RTSP). These not include regular things like to documented access to variety of features, availability for Win32 and Linux etc.
API documentation has always been not very much accurate as if it was given insufficient attention but luckily it was quite simple to figure things out. Another warning thing was that native software worked directly, without SDK: it was not very good for independent software vendors like us because there was a suspicion that SDK was something complimentary and was undertested. Fortunately however, the vendor decided to change this and their mainstream software started using the same SDK redistributables available for independent vendors also.
The first incident was recently when the vendor changed SDK implementation without changing published API and without giving any notice in documentation on one of the features. It did not break compilation or anything in our software, however it started working differently in production environment. We started receiving complaints and since we did not find any documentation changes, contacted the vendor’s support for comments and found out that implementation has been changed…
Now we got a new issue. As mentioned before, SDK’s advantage was to cover product line being constantly extended. New hardware from the product line appears to be quite sophisticated - a camera with multiple sensors. I believe this was not the thing foreseen when original SDK was designed so there was a kind of solution to workaround indexed access to individual sensor parameters in the API. However it appeared now that new products don’t support some of the older product features and SDK instead of returning a kind of “unsupported” error code to the requests, instead it messes other values. So it appeared that unified access to the product line was broken…
Everything was finally sorted out but in total it took a lot of time to. First of all, the problem due to its nature spread to production from where the dealer started receiving complaints from his client. The dealer in his turn forwarded the issue to us where we had problems investigating it because this particular piece of hardware is a kind of rare and expensive. When we gather sufficient data to think of the case as an SDK bug we forwarded the issue to the vendor.
Obviously the vendor responded with ridiculous suggestions assuming us to be complete lamers. Still we were in position to help our client and resolve the case, so spent some time to gather additional information to prove the supposition of an SDK bug. It took quite some time at our expense while finally we could work out a workaround for the problem and soon after receive a confirmation for a bug… Can we expect it to be fixed with next SDK update? “We will do this some time later”.
Why things happen this way? OK we are a small ISV with our own problems getting things work as expected. The vendor, however, is a high technology leader, well known and recognized throughout the industry, a subject of a completely different scale. Expensive hardware ans software is involved and we are still getting ridiculous problems at the output.