First of all you have to understand a bit about my background. I have never worked with IP cameras before, but I will have to access multiple IP cameras simultaneously with OpenCV very soon. Apart from that, my network knowledge is not that much good.
Now the question. I know OpenCV can access IP cameras using its URL with the help of VideoCapture. There are number of questions in StackOverflow as well. But, the IP address is something that can be changed by time to time, it is dynamic. So even in a IP cam, the IP will change by time to time. So if this is the case, does this mean every time you try to access the cameras with OpenCV, you have to find the IP address of the camera manually and change the URL in OpenCV as well? I do not need to access the cameras via the internet, accessing locally is fine, via Wifi or network cables. How can I set a fixed IP address/ URL so the OpenCV code has nothing to change every time?
PS: I navigated through lot of websites (sites from more than 5 result pages of Google search) but the answers given are either too old or not that much convincing. So I decided to walk into StackOverflow for the answer.
If you can use local network, then Yes, you should use fixed IP address....if the Camera SDK is compatiable with OpenCV this you dont have have to worry about this and you can call VideoCapture directly. Or, you could use the camera SDK to get frames directly and then copy these frames to opencv image format and use opencv. This should not be too complicated.
If your router has a DHCP reservation feature, simply tell the router to always give an IP camera a certain IP.
Thus when the camera polls the DHCP server when it connects to the network, it will automatically receive its reserved IP. Other clients without a reservation will simply receive a random IP like normal. You might even think about doing this for all your computers and devices; it's quick and easy.
Related
Is there a simple way to implement communication between two computers running GNUradio using the standard blocks set?
What I am have now is this:
On a Linux computer, GNUradio is running and receiving input from a Radio peripheral. On that computer I can see the received waveform on a WX scope. I can also use sliders and input boxes to change things like the receiver frequency.
What I'd like to do is this:
On a Windows computer, I have the WX scope and sliders. When I move the a slider or change an input box, that data gets sent to the Linux, which is still running the radio receiver on Gnuradio. The received signal goes through a stream back to the windows, and gets displayed on the WX scope on Windows.
Someone elsewhere suggested using the ZMQ blocks, however, when I tried setting up a PUSH/PULL to transmit a sine wave from the Linux to the Windows, nothing went through. The guy who recommended that approach tried the same and also could not get it working, so I think that block might be broken?
So is there any alternative blocks that can do what I'm trying to do? Preferably something well documented, and available on GNUradio-companion.
Depending on the data rate from the receiver, it's possible to encounter performance issues attempting to send raw waveform data using e.g. the UDP blocks, where the sender may print an error similar to the following:
gr::log :WARN: udp_source0 - Too much data; dropping packet.
Because the scope widgets usually only display a portion of the input data, a more ideal way of remotely visualizing the waveform might be to only send the rendered scope widget (e.g. using a remote desktop such as VNC or X2Go). Although this solution reaches beyond your original problem, it is probably easier to use in the long run for cases involving two-way GUI interaction.
For the scope widget data, the UDP sink and source blocks seem to be native to GNU Radio, and are either sufficiently documented solution or simple enough for this problem, again taking firewall configuration into consideration as #Zephyr mentioned.
From GRC, specify in the UDP blocks:
the hostname or IP address of the display computer, and
a choose port number that isn't already in use (and were you using Linux, OS X, or anything UNIX-like, not any port below 1024).
For setting variables over the network, you might try the XMLRPC blocks, as described in another answer. These were recently deprecated, however.
See my other answer for discussion of alternative if performance issues arise.
Both Linux and Windows should have firewalls which might be blocking the connections.
You need to post the error messages displayed in gnuradio-companion.
I'm trying to figure out if it's possible to stream directly from a webcam (IP Camera / Network Camera) to an RTMP Flash Server.
The purpose is to be able to set up a camera at a location and be able to stream directly from it to streaming services such as DaCast or justin.tv without the need to have it hooked up to a computer that does the encoding. All it would need is a wireless connection.
Technically the camera would have to have it's own encoder (H.264) and a place where you can configure the Flash Media Server to stream to within it's built-in configuration.
Parts of this answer comes from: AskUbuntu: Security camera system server
Certain IP Cameras, in several flavors, brand names and models, provide their own web page for setup/preview/monitor, from which you can extract the portions of code that you can use in your own project in a website.
You don't say what do you have in mind by streaming to justin.tv or other web based streaming service but if what you wish to achieve is to get the benefit of the popularity of the web based streaming service itself to gain audience, then this solution IS NOT FOR YOU.
But if you are using a web based streaming service just to gather the portions of code in order to be used in a customized website of your own, then you can use the code provided by your own IP Camera.
As far as I know, the majority of the IP cameras, as those shown in
this virtual shop, starting from $ 945.00 Mexican Pesos (almost
100 US Dollars), and this D-Link DC-900 (the majority of them
tested by me) resolves the motion detection, scheduled recording and
remote control by itself (there are just a few which features 360°
movement, remote controlled).
How to reach your cameras from outside is as easy as getting a Dynamic
Domain Name Service and to use it in your modem/router or, if you have
fixed IP then you don't have a problem, you will also be in need to
route the specific ports to the cameras and make the cameras respond
to the petitions of a specific port.
Everything can be monitored/controlled via web browser, like in this
example of my security system which is embedding 3 cameras (1 of them
remote controlled) in a single web page. (blurred where needed for
privacy).
The remote controlled camera is the one shown here, with two-way
audio (yes, you can speak to people close to the camera), wireless and
infra-red night vision. (Sorry, I don't sell these cameras but I
purchased over there in Mexico City.)
In the examples provided here I am using the portions of code of the original IP Camera web page monitoring system, as shown in the next picture:
Original DCS-900 Camera's Web Based Application
So I think this can be done directly from the IP Camera web application but as I mentioned before, if what you wish is to get advantage on the web based streaming service (for getting audience), you may wish to consider a different choice.
Good luck!
You can use CamStreamer RTMP client - An application which is running directly in Axis IP camera. The camera with CamStreamer pushes the video to any RTMP streaming service (LiveStream, uStream, YouTube Live,...).
I've read in Wikipedia that one of the ways to obtain geolocation information for a given IP is done using DNSBL. The following link is: http://en.wikipedia.org/wiki/Geolocation_software#Data_sources
Could someone explain me how this is done? And in general, what is DNSBL rather than a banning list?
DNSBL is a blacklist/database based on dns. DNS is just your api to get a specific result. Others could be HTTP or a simple local file.
IP needs routing and thus the physical machines doing that are placed in certain locations. Knowing that makes it possible to collect data where the routing points are and thus get to closest location of a certain IP address. (Knowing that there are 5 big co
http://en.wikipedia.org/wiki/Geo_targeting
http://en.wikipedia.org/wiki/LOC_record
http://en.wikipedia.org/wiki/Regional_Internet_registry
I'm setting up a iPhone tracking system for my friends, so they can submit their location to my website by their iPhone, anywhere, anytime - by WiFi or cellular data.
The website will use Google Maps for their coordination's so that my other friends can track where they are, however, it is the accuracy of the IP to coordinates to Google Maps is what I'm concerned about, exactly how accurate is it to use Google Maps that would track down the locations by an IP address?
I was thinking about 95%, but this was tested in a village which was quite fairly accurate, but what happens if it was in a city? Would this cause unaccurate locations?
Any kind help appreciated.
IP geolocation is really hit-or-miss, depending on both how the user's ISP assigns IPs and on the IP geolocation database you're using. For instance, I made a simple PHP script, IP2FireEagle, which looks up your IP. I found that the database kept placing me 10+ km to the west of where I really was. Updating my entry in Host IP wasn't the greatest, as it soon got reverted, presumably by someone also occasionally assigned that IP by my ISP! That being said, I found that Clarke has very accurate coordinates (not that this it's using IP geolocation per se but rather Skyhook's API and their WiFi geolocation database).
If it's a website for your friends and you know they have iPhones, I would suggest using its browser's support for navigator.geolocation.getCurrentPosition(). That is, get the location via Javascript and submit it to your server via an AJAX call. Even better since you want to use Google Maps, they give you a short tutorial on how get your friends' locations and then update a map.
Excerpt From:
http://www.clickz.com/822881
IP targeting has been around since the early days of ad serving. It's not very hard to write code that will strip the IP address from a request, compare it to a database, and deliver an ad accordingly. The true difficulty, as we shall see, is building and maintaining an IP database.
One of the first applications of information in an IP database was targeting to specific geographic regions. Most commercial ad management systems have IP databases that can make geographic targeting possible. However, there are a couple weaknesses in this method. The first (and biggest) problem is that, for various reasons, not all IPs can be mapped to an accurate location.
Take all the IPs associated with AOL users, for instance. Anybody who has seen a WebTrends report knows that all AOL users appear to be coming from somewhere in Virginia. This is caused by AOL's use of proxy servers to handle their web requests.
In the interest of saving space, we won't get into the reasons why AOL makes use of proxy servers. The important thing is that AOL does use them, and as a result, all its users appear to be accessing the web from Virginia. Thus, it is impossible to attach meaningful geographic location data to an AOL IP, and those IPs must be discarded from any database that wants to maintain a reasonable degree of accuracy.
Other ISPs and networks may use a method known as dynamic IP allocation for its users. In other words, a user might have a different IP address every time he visits the Internet. You can see how this might affect the accuracy of a database.
But the real difficulty in discerning geography from an IP address has to do with the level of specificity that a media planner might expect from this targeting method. The first few geo-targeted campaigns that I put together early in my career had to be accurate to the ZIP code level. This level of specificity is not practical via IP targeting.
Right this is confusing me quite a bit, i'm not sure if any of you have noticed or used the "my location" feature on google maps using your desktop (or none GPS/none mobile device). If you have a browser with google gears (easiest to use is Google Chrome) then you will have a blue circle above the zoom function in Google Maps, when clicked (without being logged into my Google Account) using standard Wi Fi to my own personal router and a normal internet connection to my ISP, it somehow manages to pinpoint my exact location with a 100% accuracy (at this moment in time).
How does it do it? they breifly mention it here but it doesn't quite explain it, it says that my browser knows where i am...
...i am baffled, how?
I am intrigued because I would love to integrate it in the future of my programming projects, just like some background understanding and it doesn't seem too well documented at the moment.
I am currently in Tokyo, and I used to be in Switzerland. Yet, my location until some days ago was not pinpinted exactly, except in the broad Tokyo area. Today I tried, and I appear to be in Switzerland. How?
Well the secret is that I am now connected through wireless, and my wireless router has been identified (thanks to association to other wifis around me at that time) in a very accurate area in Switzerland. Now, my wifi moved to Tokyo, but the queried system still thinks the wifi router is in Switzerland, because either it has no information about the additional wifis surrounding me right now, or it cannot sort out the conflicting info (namely, the specific info about my wifi router against my ip geolocation, which pinpoints me in the far east).
So, to answer your question, google, or someone for him, did "wardriving" around, mapping the wifi presence. Every time a query is performed to the system (probably in compliance with the W3C draft for the geolocation API) your computer sends the wifi identifiers it sees, and the system does two things:
queries its database if geolocation exists for some of the wifis you passed, and returns the "wardrived" position if found, eventually with triangulation if intensities are present. The more wifi networks around, the higher is the accuracy of the positioning.
adds additional networks you see that are currently not in the database to their database, so they can be reused later.
As you see, the system builds up by itself. The only thing you need is good seeding. After that, it extends in "50 meters chunks" (the range of a newly found wifi connection).
Of course, if you really want the system go banana, you can start exchanging wifi routers around the globe with fellow revolutionaries of the no-global-positioning movement.
It's a lot more simple that you think. You've signed into both your mobile and Chrome on your desktop using the same Google account. Google simply expect you will have your mobile with you most of the time. They take the location data from your phone and assume the location of your current desktop session is the same.
I proved this by RDPing into my Windows machine at home from work and checking Google maps remotely. It show my location as the same as Chrome on Linux at work.
If you don't have a mobile that is signed into Google then all they can do is lookup GeoIP data for the IP address assigned by your ISP. It will typically be wildly inaccurate.
They use a combination of IP geolocation, as well as comparing the results of a scan for nearby wireless networks with a database on their side (which is built by collecting GPS coordinates alongside wifi scan data when Android phone users use their GPS)
I've finally worked it out. The biggest issue is how they managed to work out what Wireless networks were around me and how do they know where these networks are.
It "seems" to be something similar to this:
skyhookwireless.com [or similar] Company has mapped the location of many wireless access points, i assume by similar means that google streetview went around and picked up all the photos.
Using Google gears and my browser, we can report which wireless networks i see and have around me
Compare these wireless points to their geolocation and triangulate my position.
Reference: Slashdot
According to Google Maps' own help:
Rejecting the WiFi networks idea!
Sorry folks... I don't see it. Using WiFi networks around you seems to be a highly inaccurate and ineffective method of collecting data. WiFi networks these days simply don't stay long in one place.
Think about it, the WiFi networks change every day. Not to mention MiFi and Adhoc networks which are "designed" to be mobile and travel with the users. Equipment breaks, network settings change, people move... Relying on "WiFi Networks" in your area seems highly inaccurate and in the end may not even offer a significant improvement in granularity over IP lookup.
I think the idea that iPhone users are "scanning and sending" the WiFi survey data back to google, and the wardriving, perhaps in conjunction with the Google Maps "Street View" mapping might seem like a very possible method of collecting this data however, in practicality, it does not work as a business model.
Oh and btw, I forgot to mention in my prior post... when I originally pulled my location the time I was pinpointed "precisely" on the map I was connecting to a router from my desktop over an ethernet connection. I don't have a WiFi card on my desktop.
So if that "nearby WiFi networks" theory was true... then I shouldn't have been able to pinpoint my location with such precision.
I'll call my ISP, SKyrim, and ask them as to whether they share their network topology to enable geolocation on their networks.
I know you can look up IP address to get approximate location, but it's not always accurate. Perhaps they're using that?
update:
Typically, your browser uses
information about the Wi-Fi access
points around you to estimate your
location. If no Wi-Fi access points
are in range, or your computer doesn't
have Wi-Fi, it may resort to using
your computer's IP address to get an
approximate location.
It is possible get your approximate locate based on your IP address (wireless or fixed).
See for example hostip.info or maxmind which basically provide a mapping from IP address to geographical coordinates. The probably use many kinds of heuristics and datasources. This kind of system has probably enough accuracy to put you in right major city, in most cases.
Google probably uses somewhat similar approach in addition to WiFi tricks.
So Google keep records of Wifi router location by using any cellphone
GPS that connected to that router when you use Google maps or
location on cellphone. then google knows every device that connected
to that Wifi router uses the same location.
when GPS off or no cellphone connected to router Google uses IP
geolocation