TheUberOverLord

Nice to be back here. Please check my signature for how the Nickname came about. Most recent project for any IP Camera Brand or Model as well as any Imaging device that has the ability to provide images via HTTP or HTTPS was to access those devices and display those images securely. Without giving up any DDNS or IP Address, Port or User credential information from the originating source while doing so. More here: http://www.cctvforum.com/viewtopic.php?p=243121#p243121 Note: The Interface is a free Interface. Don

Delete

Note: This Interface can be used with virtually any IP Camera Brand or Model or WebCam or other imaging device that allows Snapshots to be pulled from them using HTTP or HTTPS methods. The Interface was initially designed for Foscam IP Camera Models. Which is why it has so many references to them. Because the Forum here caches all images in Forum Posts. The images displayed here are static and cannot be changed. By simply refreshing the pages here. In many if not most other Forums, Blogs, Social Media sites and other Web Sites. One can simply use IMG tags in those places. So that visitors who view the post including the image. See real-time images at the time of viewing the post vs. static images of when the post was created: [img=http://www.saveontelephonebills.com/camera/FoscamPullImage.php] Free SecureImageDisplay Version 2.4 Released This Interface works with ALL Foscam IP Camera models and here are the current options it supports: Save Real-Time Images To Disk Real-Time Image Throttle Auto-Recovery Automatic Image Percentage Resize Insert Date Time and Custom Text Into Images One of the downsides of accessing your IP Cameras over insecure Internet connections or displaying "Real-Time" image(s) of your Foscam IP Cameras in Social Media sites, Blogs, Forums, Web Pages, Instant Messengers or even in Emails as an image or as links. Is that by doing so, you expose and show your Foscam IP Cameras DDNS and Port or ISP IP Address and Port and a User Id and Password credentials for your Foscam IP Camera. This Interface provides methods that resolve the above issues with future versions and functionality to come. Even while using HTTP unsecure access methods to any of your Foscam IP Cameras. Secure Private Use These images and their very secure methods. Contain no reference to your Foscam IP Cameras Model information, DDNS, IP Address or Cameras User credentials on where the Foscam IP Camera images originated from or how they were obtained. In fact. These methods can be used to check on your Foscam IP Cameras when you are using any Internet browser capable device that is using public or semi-private Internet access. Such as public WiFi access or even your workplace and other semi-private internet connections for your Internet connection at that time. Where you do not trust or wish to broadcast ANY information about your Foscam IP Cameras when accessing them on any risky or potentially unsecure Internet connection. Where by doing so. Could and can expose you to Identity Theft or other IP Camera abuses. If others could use that exposed information. To abuse your IP Cameras by changing their position and/or viewing their video streams at anytime and/or gain access to your IP Cameras configurations. Thereby and possibly ("Depending on the User Id Level you used to access your IP Camera when using those unsecure Internet connections") others could also learn your Email and/or FTP User Ids and Passwords for them. Why take that RISK on a unsecure internet connection when there no longer is a need to do so? Note: Once someone learns where your IP Camera is located ("DDNS and/or ISP IP Address") over an unsecure Internet connection. While also having any valid IP Camera User Id and Password information that was exposed because of using that unsecure Internet connection. They can connect to your IP Camera and based on the IP Cameras User Id level and Password that they ("Sniffed") and captured over a unsecured Internet connection. They can also determine what type of IP Camera is being used during that ("Sniffing") process. At the very minimum, they would have unfettered 24/7/365 access to your IP Cameras video streams anytime your IP Camera was online and still using that same DDNS and Port or ISP IP Address and Port and User Id and Password for that IP Camera, that they ("Sniffed") on that unsecure Internet connection. That's a "Best Case" scenario and definitely not the worse case scenario and for sure, not worth the risk. Secure Public Use Here are methods to securely display your Foscam IP Cameras "Real-Time" in Social Media sites, Emails, Forums, Blogs, Web Pages, Instant Messengers and anyplace where you can include an image or links in your post. As well as your own web pages which can now include a "Real-Time" Snapshot image of your Foscam IP Camera. Without needing to include or expose any reference to your Foscam IP Cameras DDNS, IP Address or Foscam IP Cameras User credentials. With or without your own custom text and/or date and timestamp embedded in the actual image(s) displayed. These images are in "Real-Time". If you right click on the images displayed here. You can see that you cannot tell where the Foscam IP Camera is located or what User Id or Password for your Foscam IP Camera is being used to get the image from your Foscam IP Camera. The examples are using a 160x120 resolution for demo purposes. But you can display any camera resolution for your Real-Time Snapshots or automatic refreshed Snapshots of your Foscam IP Camera on Social Media sites, Blogs, Forums or anywhere that allows you to add an images and/or links to your post. Including your Emails. This is an excellent method for example. To display a current single image or automatically refreshed images of any Foscam IP Camera. MJPEG or H.264 based, in Real-Time, on a web page at the time a visitor visits and views that webpage. Without giving up any information about your Foscam IP Camera location or user credentials. While and when doing so. Both these examples require having access to a Web Server with PHP. In some cases. Web Hosting services do NOT allow access to non-standard outgoing ports. Meaning a port other then port 80. If your Web Hosting service will not open a non-standard port to your current Foscam IP Cameras port. You will be forced to use port 80 for your Foscam IP Camera, to get this to work. The php script automatically checks and reports if this is the case. Please also note that using these methods, can be resource intensive as well. If you use the second example shown here and pull your Foscam IP Cameras image from disk unless it's older than x seconds old. You can control and minimize these resources if needed. So if you are not hosting your own server and will have high traffic volumes to the web pages you post your Foscam IP Cameras images on. It's a good idea to at least check and benchmark any resources on any hosting service that you may use these methods on. Here are the five files required to use both of these examples. Which Includes the actual php examples show here all in a .zip file: The first example. Simply pulls a current image from your Foscam IP Camera in "Real Time" and displays it on the web page that references it. The image you see above. Is a Real-Time image that was just created when you viewed this Forum post. Not an old image from when this post was created and posted here in the forum. But a Real-Time image when you viewed this Forum post here. You can do the same on any Forum, Blog, Social Media Site, Web Pages, Instant Messengers and in Emails that allows you to include images and/or links in your posts. Including your own Web Pages. Even if the you are not allowed to include images in your posts. You can instead include a link that when clicked on can display a Real-Time image of your Foscam IP Camera. With or without custom text included in those images. Without exposing any information about your Foscam IP Cameras DDNS, ISP IP Address, Port, User Ids or Passwords to do so. Example: Image Without Custom Text: http://www.saveontelephonebills.com/camera/FoscamPullImage.php Image With Custom Text And Custom Colors And/Or Date and Time: http://www.saveontelephonebills.com/camera/snaptime2.php You can also use these same secure methods that do no expose any information about your Foscam IP Camera. Such as your DDNS, ISP IP Address, Port, User Ids and Passwords. To display your Foscam IP Camera using automatic Real-Time images that refresh at the rate you desire by embedding the logic in a Web Page or including a link in Social Media sites, Blogs, Forums and Web Pages, Instant Messengers and your Emails. Example: Images Automatically Refreshed Without Custom Text: http://107.170.59.150/SecureRefreshWithoutText.htm Images Automatically Refreshed With Custom Text And Colors And/Or Date and Time: http://107.170.59.150/SecureRefreshWithCustomText.htm Images Automatically Refreshed With Multiple Cameras At The Same Time ("Same camera being used for live demonstration purposes"): http://107.170.59.150/TwoCameras.htm Note: You can display as many Foscam IP Cameras at the same time as you wish. Each configured differently or the same. Each with or without custom text and using any combination of Foscam IP Camera models with each being the same or different sizes. In any display configuration you wish. With ALL Foscam IP Cameras being displayed. Using these totally secure methods. These are NOT a static images. They are dynamic and will also automatically change in size based on what size your Foscam IP Camera is set to display for Snapshots. Even when you change that size using the standard camera interface that comes with your Foscam IP camera. The Web Server is not storing any image file on disk, in the above examples. This means that if your camera was offline or not available. That no images would be shown. This example is simply acting as a go-between for where the images will be posted and the Foscam IP Camera. So that the location and User credentials for the Foscam IP Camera remain private and hidden. The second example is NOT dynamic for resolution with custom text and/or Date and Time. Meaning that IF you change your Foscam IP cameras resolution and use text in the image as is being used in some of the examples. You will need to change the x and y coordinates of where that text is overlaid in the image. Otherwise. The text will be in the wrong place. When or if the image size is changed. This example actually does create a single jpg file on the web server, which is reused as needed. This can also help you control web server resources when using methods like this unlike example #1, which will try and pull a image, each time from your Foscam IP Camera. This second example, has many benefits over the first example, shown here. 1. It stores an image on disk so that IF your Foscam IP Camera was offline or not available. The last image stored on disk will be used and displayed. Not letting anyone know your Foscam IP Camera is offline or not available. Assuming that your image is not using a timestamp of course. 2. You can set the number of seconds since the last image was written to disk to get a fresh image directly from your Foscam IP Camera. So that you can better control resources when/if needed. Only getting a fresh image from the Foscam IP Camera when or if the image on disk is greater then x seconds old. 3. Allows you to insert your custom text and/or a date timestamp into the actual image and store it on disk. Technically it is also possible to add your own logo to your Foscam IP Cameras images displayed, with few changes to do so. 4. Allows you to define the image size no matter how large the original Snapshot image that was pulled from your Foscam IP Camera is. This is especially important for the Foscam H.264 based IP Camera models that have very large Snapshot images. So that you can present a smaller size or a larger size of the original image if needed. While keeping the aspect ratio of the original Snapshot images. The image you see above is a "Real-Time" image that was created when you loaded this web page. It also creates a single image file on the web server, that is reused and updated when this happens and that file can also be accessed directly as well. Again, with no exposure of where the Foscam IP Cameras DDNS, or IP Address that created the image is located or any User Credentials for the Foscam IP Camera that produced the image above. http://www.saveontelephonebills.com/camera/webcam.jpg Note: If you use the link above to get the file created by the image above, multiple times. Your browser may cache the file when using the link. Because the request to get the file, is not a unique request. However, the image shown above. Will be unique each and every time your refresh this Forum post web page, because it forces the image to be unique. Both of these examples are TOTALLY secure methods. Simply using different configuration options available In the Interface. Allowing you to view your Foscam IP Cameras over unsecure Internet connections as well as share images of your Foscam IP Cameras. While providing total ambiguity about your Foscam IP Camera Model and maintaining the privacy of the DDNS, IP Address, Port and User Credentials of your Foscam IP Cameras. You can create different copies of the Interface configured to be used for different purposes for the same Foscam IP Camera and you can use this Interface to display multiple Foscam IP Cameras at the same time. You can also reference and use any images created by the Interface that are stored on disk as the last image directly. The Interface also allows you to access any Foscam IP Camera model even MJPEG based camera models using HTTPS if desired. Accessing the MJPEG IP Camera models using HTTPS is normally not supported. This can be very helpful if you wish to add your Foscam IP Camera in HTTPS based Web Pages. Please note the Web Site being used for the examples is using a self-signed certificate which is why you will see a warning when using the example HTTPS links below: https://107.170.59.150/ipcamera.php https://107.170.59.150/TwoCameras.htm As you can see in both these examples. They even allow you to use "Real Time" images of your Foscam IP Cameras on other websites. Like Social Media sites, Blogs, Forums, Instant Messengers like Skype, Yahoo and others and in your Emails and anywhere you may post. That allows images and/or links to be included with your posts. Not simply on just your own Web Pages. In some cases, if your images are sized correctly. You can even use this Interface as your profile picture in Social Media sites, Blogs, Forums other Web Sites and even with some Instant Messengers. Allowing you to have Real-Time images of your Foscam IP Camera instead of any static images you currently maybe using there. You may also be interested in how to include your Foscam IP Cameras ("As well as other Brands and Models") as the video source used in your Instant Messengers like Skype, Yahoo, MSN and many others. If so, please see this as well: http://foscam.us/forum/you-can-use-your-cameras-in-skype-yahoo-other-messengers-t8712.html#p42112 Don SecureImageDisplayV24.zip

Note: This Interface supports any IP Camera Brand and model and/or image based device that allows images to be pulled from it using http or https methods. Not just Foscam IP Camera models. A new version 2.0 was released: Changes; 1. Now supports using Curl methods when the image is pulled from the IP Camera and no custom text is used and no disk recovery is used. 2. Includes example HTML that uses the php code for automatic image refreshes based on a timeout value in Milliseconds which you configure. Please see this for the new version: http://foscam.us/forum/secure-methods-using-php-to-display-your-ip-camera-t8721.html#p42139 This allows the same php code too support as many methods as possible including being very fast but also being totally secure. So that no information about your IP Camera is exposed of any kind. Such as DDNS, ISP IP Address, Port, User Id or Password. While displaying your IP Camera publicly on or in a webpage. These methods can also be used when for example you are using a public WiFi interface with whatever device you have currently and you don't wish to expose any of your IP Camera information. But you want to use that device to see your camera in real-time using a single Snapshot or automatically refreshed Snapshot images. Otherwise. You run the risk if you are using an Admin User level Id for your IP camera with a public connection of exposing your IP Cameras information where someone could obtain Email and FTP server user and password information. If that information is stored in the IP Cameras configuration. When you use a unsecure connection. Don

Even if you currently don't have a Web Server or Hosting Service to host php examples like this. It's easy to start doing so. For as little as $5 U.S. dollars a month. Using Hosting Services like as just one example DigitalOcean's Digital Cloud SSD ("Solid State Drive") VPS ("Virtual Private Servers") Hosting Services: Note: If anyone needs help setting something up like this. Please ask here. This was a first for me as well. Which I used specifically for the examples shown in this my last post here showing secure automatic image refresshing. As to not be subjected to any resource restrictions by a Shared Hosting Service. Which I used for my other examples here and also use normally as well. Without any need to use or register any Domain name. Also saving money. Where you can configure your own flavor of Linux systems and options. To do things like this and also store other data from your IP Cameras. Like your own FTP interface without being subjected to any restrictions a Shared Hosting Service may have. Such as blocked ports, memory usage, process usage and other limits they may impose. These are the Web Server resources being used with one copy of each example above being run at the same time Above Web Server was configured for these example with: Ubuntu 12.04.3 x64 1GB Ram 30GB SSD Disk 2TB Transfer per Month Bandwidth Maximum Apache/2.2.22 (Ubuntu) PHP/5.3.10-1ubuntu3.9 with Suhosin-Patch Click to see the php options I installed for this example Varnish MySQL memcache swap file FFmpeg avconv The beauty about going this route, for IP Camera owners. Is that you can control every aspect of what software you use for your Web Server as well as stop/start the Web Server as needed to make changes. The IP Address is unique and can be used directly without any Domain name if needed. As the example here is doing. The Web Server is your personal Web Server. Without being shared by others. So you have a clear view of the resource being used and also knowing that all those resources are your resources. So that you can do Web Server Tuning as well. It can also support as many Domains as you wish. In the event your currently have Web Sites and are under restrictions on a Shared Hosting Plan. It's a great alternative method to store Snapshots and Videos for your IP Cameras, without the need to run your own system to do so 24/7/365. It also has built-in RAID ("Redundant Array of Independent Disks") so even a disk outage would not cause a loss of IP Camera files. After all the purpose of IP Cameras are security. So, having fault-tolerant disk storage is important. Even more so for multiple IP Cameras. I also wanted to set the stage for my next posts here. Which will be about providing secure real-time video from your IP Cameras and generating SMS messages, when your IP Cameras detect alarms or go offline or become unavailable. While many IP Cameras have the ability to tell you when their ISP IP Address changes. None have the ability to tell you that they went offline and are not currently available. Don

Unlike the misunderstood concept which varascope had. That by simply encrypting the HTML source code used to access the IP Camera. Could/Would by itself, protect the IP Cameras, DDNS, IP Address, Port, User Id and Password information from being exposed. Which is not true or correct. You can use tools like ANY browser debugger included with ANY browser, Fiddler2 or Wireshark to confirm that no information of any kind is exposed about the IP Camera used in these first two secure examples shown here. The third example shown here is a non-secure example. Fiddler2 was used here to demonstrate. What information a client device would have access to, about the IP Camera being accessed. When that client device is using HTTP and HTML on a client device to access a IP Camera. Using the secure and non-secure methods. With or without HTML encrypted source code. The results would be the same. Here are also examples of using these methods for totally secure access to your IP Camera with automatically refreshing images by using the php code shown here inside HTML. Viewing a IP Camera in real-time. That works using ANY Internet browser capable devices that are running on any Operating System which are using any browser. You can view the HTML source code for each example to see what's being done: http://107.170.59.150/SecureRefreshWithCustomText.htm Note: The below is the servers IP Address when the above link is used. NOT the IP Cameras IP Address Note: There is additional overhead involved in the above example due to modifying the images in real-time with custom text such as date and time. Whereas leaving the image as it was received cuts down this overhead: http://107.170.59.150/SecureRefreshWithoutText.htm Note: The below is the servers IP Address when the above link is used. NOT the IP Cameras IP Address The above examples. Have no linkage of any kind as to what the IP Cameras DDNS or IP Address, Port, User Id or Password is. As stated earlier here. These secure examples are substantially much slower then using non-secure methods like the example below. Which also works with any Internet browser capable devices as well. Such as this: http://107.170.59.150/GenericBIV31.htm Note: The below IS the IP Cameras Address when the above link is used. Including DDNS, ISP IP Address, User Id and Password Information Which would still be exposed even with varascope's encryption method concepts. Which are and were incorrect. When using HTTP and HTML alone from any client device. This is why php was chosen for these methods. Because not all IP Cameras support HTTPS and even if they did. There are easy methods to get the same IP Camera information using tools like Fiddler2 on the client device side. Whereas by using php. This is not possible. The results of all the two secure and one insecure methods shown here for IP Camera automatic refresh turn around times for each image are: Secure With Custom Text: 450 Milliseconds average total turnaround time per requested image Secure Without Custom Text: 250 Milliseconds average total turnaround time per requested image Unsecured: 44 Milliseconds average total turnaround time per requested image Of course you can use these same secure or non-secure methods with single snapshots or automatic image refreshes using multiple IP Cameras on the same Web Page. That can be any mix of IP Camera Brands and Models and types such as MJPEG or H.264 based. One Example showing something like this. Using one IP Camera to represent multiple IP Cameras for live demonstration purposes. The live demo below is throttling each camera shown to a maximum of 1 FPS ("Frames Per Second") for live demonstration purposes: http://www.saveontelephonebills.com/camera/EmbedWebPageExample.htm Don

IMPORTANT While I can't speak or claim that these limitations are the same for ALL IP Camera Brands or Models. I can say that these limitations DO Apply to ALL Foscam IP Camera models. Generally all IP Cameras have some finite limit of concurrent Long-Term and Short-Term maximum connection limits. They could be lower or higher then these. Foscam IP Camera models have a limit of four concurrent formally logged in connections to a camera. There are two types of connections to IP Cameras in general. Long-Term and Short-Term connections. Long Term Connections These four concurrent formally logged in connection maximum limits can be reached. When using any combination of: 1. Copies of the Standard Camera Interfaces that are currently running anyplace for a specific IP Camera. 2. Any copy of a Standard Camera Interface that includes another Foscam IP Camera in its Multi-Device list that is currently running. Counts toward one connection for any camera defined in that Multi-Device list. 3. Third-Party Software. When this maximum of four concurrent formally logged in connections is reached. Any requests to formally logon to the Foscam IP Camera. Will be denied until and unless one of those connections is freed up or you power down/up the camera to release those connections. This has and does confuse many Foscam IP Camera owners. When suddenly they can't seem to logon to their IP Cameras. Especially those that maybe using multiple things to the same camera at the same time. Such as a NAS/NVR, mobile devices and copies of the Standard Camera interfaces that come with the Foscam IP Camera trying to all run at the same time. In the past. There have also been issues with some third-party applications that are for the Foscam IP Camera models. That think that they have lost communication with a IP Camera. They then create a new connection with the IP Camera but don't close the old connection to the IP Camera. Eventually causing the Foscam IP Camera owner to become locked-out of accessing their own Foscam IP Camera. Until and unless that third-party application is completely stopped. One can simply stop using the third-party application for a period of time to see if your lockout issue also goes away. When that third-party application is completely stopped. It should be noted that some third-party application have released new versions of those applications that have resolved this issue. Others have not. It's easy to emulate and see this lockout take place. By simply creating 4 different copies of the Standard Camera Interface that comes with the Foscam IP Cameras. In their own browser windows and logging into each one. Then attempting to open another browser window to create a fifth copy of the Standard Camera Interface. That will NOT be able to be log on. There are limits to the number of video streams from a Foscam IP Camera model as well. But they vary. The number of video streams running on a Foscam H.264 based IP Camera model does not count toward the formally logged in limit of 4 concurrent connections maximum. However, they do count for the Foscam MJPEG based IP Camera models. This is why one would not want to place a link in public Web Sites to access your Foscam IP Cameras video streams, directly from the IP Camera. Especially more so for Foscam MJPEG based IP Camera models. Because if enough people were viewing your video stream ("Directly from the IP Camera") you can end up locking yourself out of being able to logon to your own Foscam MJPEG based IP Camera. Short Term Connections Short term connections are those that are used for CGI request/responses from the Foscam IP Camera models. Such as getting a single Snapshot. The connection is closed as soon as the Snapshot is received so it does not linger around like a long term formally logged in connection does. Because of this. The limit for these short term connections is a maximum of 80 concurrent outstanding requests in-flight before requests are refused. Here is an example to better explain. What in-flight means: http://www.saveontelephonebills.com/camera/NewWorkingDemoVisitor.htm Note: The reason why these secure methods are NOT used for the above example. Is because when using these secure methods for multiple Snapshot requests from a IP Camera in quick succession. The FPS ("Frames Per Second") rates are less then 1 FPS on average. Whereas. The above unsecure methods to get as many Snapshots in quick succession from a IP Camera can reach FPS rates as high as 10 FPS. So you do have a choice of using secure or unsecure methods. In the above example Snapshot images are automatically refreshed and seen by anyone viewing the above. There could be 100 people using the above and the Foscam IP Camera would never refuse any of the Snapshot images being automatically requested for any of the viewers. Because there may not be more than 75 requests for a Snapshot at any moment in time in-flight. Meaning requested and not yet responded to. So one can't say for example. I can only have 80 people using the above at any given time without others being denied as can be said with the formally logged in long term connection limit of four. Even if this limit of 80 is reached for short term connections. This would not contribute to using any of the four concurrent maximum formally logged in connections. So, reaching the limit of 80 here has no cause and effect to denying Foscam IP Camera owners access to logging into their Foscam IP Camera. This is why for example. One would NOT want to post a direct link to your Foscam IP Cameras Standard Camera interface on a Forum, Blog, Web Site while posting your User and Password information for them to logon as a Visitor or Operator User Level Id. Because if enough people were using that link you provided concurrently ("Four"). You the camera owner. Would be denied being able to login into your own camera. Until one of the four formally logged on connections is freed up or you power down/up the camera. I thought this was important information to share. Since very few Foscam IP Camera owners are aware of these maximum limits. This is another good reason to use methods like this when you wish to post current images of your camera in publicly accessible Web Sites. Because if you use the save last image to disk option with this Interface. Then if your camera hit this 80 short-term connection limit due to too many people trying to access your camera for a current Snapshot of your IP camera. The last saved image to disk would be presented when or if this maximum limit of 80 was reached. As stated earlier here. Other IP Camera Brands and Models might have lower or higher maximum limits for their connections. But this Interface is still capable to do this for all IP Cameras in all cases. Because when or if this limit was reached. The IP Camera will simply appear to be offline or unavailable which the Interface is capable, as is, to deal with. Don

Yes. a single real-time Snapshot request to the IP Camera. With the option of. If that request fails to pull the last image saved to disk. It should be noted that as an option you can also pull the last image from disk if it is less then x seconds old. So that you can decided how often you wish to make a real-time request to the IP camera for a fresh image as well. Don

I am glad you now see what these methods are doing. As far as I know. There were no quick, easy and secure methods that IP Camera owners currently had available to them. Who happen to also have access to a web server to display a single current image of their IP Camera without exposing the IP Address, DDNS, Port, User Id and Password for that IP Camera. In publicly accessible Forums, Blogs, Web Pages and Emails. With easily configurable options and choices when doing so, That supported all these features in one interface that was also free: a. Display a single real-time image of their IP Camera in posts they create on Forums, Blogs, other Websites, their own Websites and in Emails. Using simply IMG Tags in posts or HTML img src= statements in Websites and Emails or by using a secure direct link. That when visitors see those posts, in those Forums, Blogs, Web Pages or Emails. Now and in the future. That those visitors see a current image of the IP Camera instead of a static image of that IP Camera in those Forums, Blogs, Web Pages and Emails. That could and would be hours, weeks, months old. b. That the IP Camera owner can have the current date and time and/or multiple lines of custom text, automatically included in those images. When each unique visitor sees their IP Cameras image. c. That the IP Camera owner can have those images automatically resized as well. So that if the original image from the IP Camera is very large they can display the image to their required size. While also keeping the aspect ratio of the original image. Example: An IP Camera owner may have a Web Site. They may want a large real-time image on their Web Site with a date time stamp and custom text. They ALWAYS want each visitor who views their Web Page to see a current image of their IP Camera. The IP Camera owner may also want to display the last image on disk for their IP Camera. When someone visits their Web Site and their IP Camera is offline or not available. So that their Web Site will never show a missing image icon. When or If that happens. However they want to show off their IP Camera and what their IP Camera is viewing when they post in Forums, Blogs and other Web Sites or when they send Email to others. The IP Camera owner can use another copy of this to have the images not include date time, be smaller but still include custom text. The IP Camera owner may decide to configure this copy to only go get a fresh image from the IP Camera. If the current last image saved on disk from the IP Camera is older than one minute old. So that until that last image on disk is one minute old. Any visitor visiting the Forum, Blog, or other Web Site or Email. Will not be requesting a real-time image from the camera. Each and every time. Even if the Forum, Blog, other Web Site or Email provider does not allow images to be included. The IP Camera owner can still can use a link to the php code in their posts and Emails. Allowing people to click on that link and see their IP Camera in real-time securely. Without exposing the DDNS, IP Address, Port, User Id or Password for their IP Camera when doing so. Example: "Hey Check out my IP Camera. See what its viewing right now: Click here" d. That the IP Camera owner can decide how often an actual real-time image is actually pulled from the IP Camera when visitors visit these Forums, Blogs, Web Pages or Emails where the image for the IP Camera was posted or placed or sent vs. getting a image from disk instead. e. That the IP Camera owner can have the last image saved from their IP Camera displayed as that image automatically. When or If their IP Camera happens to be offline or not available. Details When an image is used in a Forum, Blog, Website or Email. The image has a URL as the reference. Example: http://www.saveontelephonebills.com/camera/snaptime2.php ("0 second delay. See below") The php code then has the ability to do different things based on how you configure it. Request to display IP Camera image received to the php code: 1. If the age check option is used of how old the last image saved on disk must be before a real-time image request is sent to the IP Camera ("Must be > x seconds old") and the save last image to disk option is also set. Then if the image on disk is less than x seconds old grab the last image on disk instead of making a real-time request to the IP Camera for a fresh image. All Done. Note: You define the value of x seconds. In the configuration options. 2. Pull a real-time image from the IP Camera: a. If IP camera is offline and the save last image received on disk option is being used then pull last image saved from disk. Reply with last image saved on disk. All done. b. If the IP Camera is offline and the save last image to disk option is NOT on. Then reply with empty image. All Done. c. If IP Camera is online get real-time image from IP Camera. 1. If resizing option is being used. Resize real-time image received from IP Camera. 2. If date time option is being used add current date time to image. 3. If custom text after date option is being used. Add text after date on same line in image. With or without date time on same line in image. 4. If custom text is on. Add custom text to custom text line in image. 5. If save last image to disk option is on. Save image to disk. 6. Reply with real-time image received with any modifications above. All done. Note: Only the last image received from the IP Camera is saved to disk when the save image to disk option is used. So, there is no file clutter. The same .jpg file will always have the last image from the IP Camera in it. The .jpg file of course can also be accessed directly without the need to invoke the php code assuming that at one time an image was placed in .jpg file. Since the .jpg file included with the php code is initially empty. http://www.saveontelephonebills.com/camera/webcam.jpg <- Directly to where last saved image is stored, no php required. Example of 5 second delay where until the last image on disk is at least 5 seconds old. A real-time image request will not be sent to the IP Camera to get a fresh image until the image on disk is at least 5 seconds old. So the response to the request until then is using the last image stored on disk. After opening the page below. You can refesh the browser page and note that the time will not change before 5 seconds is up as you refresh the browser page. Because no attempt will be made to get a real-time image from the camera until the image on disk is at least 5 seconds old. So until the image on disk is 5 seconds old. The image on disk will be used instead of a real-time image from the IP Camera as a response: http://www.saveontelephonebills.com/camera/zzSecureFinal.php Whereas this php version is configured with 0 seconds set. So when the camera is online and available. Each time you make a request for an image from the IP camera. A real-time image will be pulled from the IP Camera: http://www.saveontelephonebills.com/camera/snaptime2.php You can refersh the page when using the above and see that the time in the image changes each time. Showing that the image was received in real-time from the IP Camera. Because if the image came from disk that time would remain the same. While this version of the php code above is always getting a fresh image from the IP Camera. If the configuration option to save the last image on disk from the IP Camera is enabled and this IP Camera were to go offline and become not available then and only then, would that image on disk be used instead of a fresh image from the IP Camera. As you now realize. There is no stream and only one single Snapshot from the IP Camera being displayed for each request. Don

Getting back on topic here: Does anyone think there should be Curl methods added to these methods? Currently they are using php GD methods. Which are somewhat slower then Curl methods. That said. When doing benchmarks using Curl methods. I found that more resources were being used for longer periods of time. Meaning the Curl process took some time to go away after use. Many hosting services limit the number of processes that can be used at any given time and the only reason why I have not added a selection of choosing php GD or Curl to do these things is I did not want to have anyone hit a resource wall by their Hosting Service when/if too many Curl processes were running at the same time. Please note that I am aware of the multi option for Curl. But in this case. It would not help much by using it. Any feedback from others on this will be welcomed. Don

varascope. Since your encryption example was defeated by me here both easily and quickly and shown to NOT be secure, in any real-world way. After I took up and accepted your challenge. In a prior post here: viewtopic.php?p=242097#p242097 If it were me. I would warn anyone whom you told that your methods were secure. That in fact. They are not and were not. Secondly, I suggest you be more careful in the future. ("Whom") you ask to challenge you on security methods. More so, when they have many decades of experience, in that field of expertise. As I have attempted to say here, many times. I fail to see. How your methods could possibly apply to a ("Stand-Alone") .jpg image that includes no HTML content of any kind. Your methods still focus on HTML content. There is NO HTML content being used in these methods. There is simply a ("Stand-Alone) .jpg image being produced. With NO HTML content included. One could use an image viewer to display these images produced by these methods. There is no requirement to use a browser to view or see the images produced here. So HTML content or the encryption of HTML content does not apply to these methods. Secondly. While you may think making the HTML source code unreadable is somehow protecting the communication between that HTML source code and a IP Camera. That by somehow doing that can and will protect any information that flows from the HTML source code from/to the IP Camera. You would be sadly mistaken. All one would need to do is run tools like Fiddler or Wireshark. While running your encrypted HTML source code and all communications from/to that HTML source code and the IP Camera. Would be IN the CLEAR. Including the DDNS and/or the IP Address, Port, User Id and Password for that IP Camera required to get whatever your request was to that IP Camera. So. Encrypting or not encrypting HTML source code that communicates with a IP Camera directly. Cannot and will not ever be secure. When that HTML source code ("Encrypted or not Encrypted") is accessing a IP camera directly, using HTTP. Don

That is my point. "displaying a "Real-Time" image of your IP Camera" In the OPs example you know the URL to the camera and the port of the source. But your displaying a refreshed JPG image. This is at least 8 years old using this method. You really should look at the php source code to have the facts of how processing is being done for these methods, instead of using your pure speculations and allegations here about how these methods actually work. There is no "Displaying of a refreshed JPG Images" going on here with these methods. There are options, which are ("Optional") to use a disk image based on how old the last image received on disk is and when the real-time image source provider, is offline. Those are options not mandates. Otherwise, normal processing using these methods. Is NOT using or displaying, refreshed images. Optionally images can be modified with custom text or resized but even then, there is no image refreshing going on. So please instead of conjecture, speculating and assuming what's going on here with the processing methods being used here, review the php source code. I am beginning to become fascinated by how you are so willing to criticize these methods using incorrect assumptions based on your theories of what processing is being done here. When the php code is readily available for you to review. So that you no longer would have any need to continue to speculate and continue to use conjecture on what's going on here. The last sentence is the part I am trying to say, you can display the live image so everyone CAN SEE yet completely hide the source (IP address or url it came from), hide username, hide password and hide the display method. The stream possibly could be encrypted itself but by simply encrypting the method alone protects your source. In the OPs method using CGI doesn't hide the source. If a hack attempt was to be made, 90% of the information needed is displayed. 1. We know the Make 2. We know the model 3. We know the IP 4. We know the Port. With a port scanner since we have the IP we can further check other open ports. 5. We can also see the JS and the structure So how is this protecting anything? User and password Yes but that is just a speed bump. What I posted was the code on a website that does display images. Depending on the level during compile you would be lucky to even see that. Let me find a URL I can put up a demo video that you can try to reveal anything. I will also try to find an older machine that we have .jog images on as well and post both on there. I think live video over refreshed images is better any day. Now I would like to know if this is truly as secure as I think it is. Our coders have ego ballons that occasionlly I like to pop. 1. Your example does not apply to hiding all the source providers information of real-time .jpg images they produce. Which then still can be used normally as ("Stand_Alone") .jpg images in Forums, Blogs, Websites and Email. 2. If you can't already see what these methods are doing using the examples I have provided here and are also not willing to review the php source code for these methods. To see that no IP Address information as well as any User credentials that may have been required for the originating source to get these images, is associated in any way. With these images produced by these methods and that nothing else, needs to be done to achieve or enhance that. I can't make it any clearer then I have already tried. Which again. Is why I ask you to review the php source code vs. speculating and making the incorrect assumptions that you are, of what's going on here when these methods are used. 3. Please read the "About Me" link here if you require doing so. I have a very long past history of dealing with encryption methods and if I thought it would even be somewhat helpful and meaningful in this case. I would have used encryption methods. But, encryption would not be helpful or meaningful in this case. It would simply be unnecessary and unrequired overhead in this case. So, IMHO, using encryption is ("Overkill") for what the purpose of what these methods are intended to do. These methods have no need to hide any image data or any other data by means of encryption. These methods need to be able to display a valid ("Stand-Alone") .jpg image as a normal .jpg image while being able optionally, to enhance that image by adding text and/or resizing that image. Which they do. The image is meant to be seen. There is no reason to create the overhead of encryption for images meant to be seen. Again. You are comparing the encrypting of an entire web page or parts of a web page ("contents") and trying to compare that somehow, someway, to be some effective alternative to these methods being used here. Which are using a single ("Stand-Alone") .jpg image and no HTML, in their content of any kind. Your method is not comparable or even compatible with the end-goal of these methods. Because it's HTML based and these methods are not trying to hide an entire web page or even parts of a web pages ("content"). These methods are used to not expose the real-time sources information that provided the image ("There is no video stream or constant data stream involved here"). Not the IP Address of the source, not the Port of the source, not any User credentials that may have been required to get the actual image from that source. Producing not a web page, not part of a web page, but a single ("Stand-Alone") .jpg image that optionally can be enhanced and optionally the same can be done, with the last image received by that source. When that source is not available. 4. Many if not most Forums, Blogs and Websites that allow people to post messages. Do not support including video feeds in posts there. While some may support allowing references to YouTube videos. Those videos are not generally, real-time videos. Additionally. Many ISPs have monthly limits which are very easy to exceed when displaying a IP Cameras full-motion video output 24/7 potentially causing the average IP Camera owner to have their account suspended or charged more. Even when using a server to feed a single video stream to all clients. Which is another reason this method was not used. There are many services also that already support those methods that one can use. Since that is the case. This is why. These methods are using ("Stand-Alone") images. I have many other examples, that use many other methods, for many other things for IP Cameras. This is one example. That serves one purpose. The other examples. Serve other purposes. Sorry to say. You are comparing apples to an oranges. With examples that don't apply to these methods. Yet you continue to suggest that somehow your example can and could be an alternative to these methods when the one example you have provided. Cleary shows, it's not related to the subject matter in this thread. Which is to provide a ("Stand-Alone") .jpg image ("Not web page content") which can be displayed using normal methods, from a IP Camera in Forums, Blogs, Websites and Email as a ("Stand-Alone") .jpg image. Without exposing any information about the source of that ("Stand-Alone") image. With additional features included of course. Forums, Blogs and Websites don't allow you generally, to add your own web page ("content") as part of your posts content there. Unencrypted or encrypted. So, your example, has no application, for what these methods are doing and are capable of doing. Because, generally. Forums, Blogs and Website DO allow you to add ("Stand-Alone") images in your posts there using things like IMG tags. Even if you managed to also hide the actual source of your example data. Your post would still be rejected for trying to use web page content in a post. In virtually, all real-world cases. That would be a "Best case" example. Since that is the case. Then it's impossible to use your example in virtually all cases, where people can post messages. Where these methods do work now. This means that your example could not and cannot ever become an alternative to these methods as your example is now. But. We can pretend ("For the moment") that somehow, someway, you were able to create some magical way to make a Forum, Blog or Website ("eat") your encrypted web page content in a post you create there. You still have done nothing to show me, how you plan to hide the provider of that web page content, as you post, using that web page content, on these Forums, Blogs and Websites. While there maybe needs to encrypt a web page or parts of a web pages content in other circumstances. That does not apply here. This is not one of those circumstances. Since the end-goal IS to display a normal ("Stand-Alone") .jpg image in the end and not to create additional overhead. It would make "No sense" in this case, to add the overhead of encryption. When and where it's not required or even needed. IMHO. You truly, so far. Have managed to take this thread topic on a tangent. At this point I am not sure why you have not created another topic about HTML web page and partial HTML web page content encryption? Because so far. What you have supplied here as a claimed potential alternative to these methods, is a obfuscation of HTML source code web page content ("Non-working example"). Which is not functional, compatible or comparable, with the ("Functional and Working") methods being shown and used here. Which is a single ("Stand-Alone") .jpg image being used in posts in Forums, Blogs, Web Pages and Email. Without any of the original source that provided that image, exposing any information as to who provided that single ("Stand-Alone") .jpg image. Most likely, digging up a video about encrypting HTML web page content and posting it in this thread. Won't help get this Forum topic off the tangential path which you have managed to take it on, so far. I also don't know many people that enjoy copying code from videos. Maybe that's just me however? Please feel free to review the php source code at your leisure, for these methods. So that you can have more accurate facts, about the processing being used here, to produce these methods. So that if you wish to continue your critique of these methods being used here. At least you will and can be dealing with fact, not fiction. Thanks Don

Ever play the game called Bull...t? I'm calling it here. Code can be encrypted as shown below. Further more, inside the code we can add additional code that viewing source is not allowed AND made almost impossible to decipher. Additional we can encrypt the code with bonding specific to a URL. You should not be able to copy the code and run it on your site to sniff any user/password data. You will receive a 404 page not found error. For testing purposes, I would challenge anyone to tell what url this came from and any pertinent information. If you have a website now that has streaming from your IP camera working, PM me and I will encrypt it for you to see if it works on your site. This is not for all members, just the OP to show it is possible. varascope. Please don't take offense. But your example. Has nothing to do with any of the methods shown here and their purposes and does not protect the information of the real-time source of a .jpg image. Your example also, won't work in a IMG Tags or in an HTML IMG src= or in Email as a .jpg image. [img=<Your Code Here>] Try it here. So. Since that's the case? What's that got to do with these methods? The end-goal of these methods is not to encrypt the data of the image so that the image could never be displayed using normal methods ("Which your example is not even doing anyway"). The end-goal of these methods is to protect the source of where the real-time image came from and any required User credentials that were required to get that real-time image, from that source. While displaying the image, using normal methods. Not ("trying") to hide the image or ("trying") to make it impossible to display an image, using normal methods. Different end-goals. This is more the inverse of an anonymous proxy. With additional features. Where the real-time image source providing the images. Does not wish to expose what its IP Address location is, what its Port is, or any User credentials that were required to get the real-time images it provides, in any way, to the client(s) receiving the images. Whereas a client, would normally use an anonymous proxy. To not expose its IP Address locaton to a server. That it wished to access. It's more complicated to demonstrate the concept here. Because the Forum imports images included in it. Automatically. Which in general. Is not normally the case. For most Forums, Blogs, Websites and Email. Because of that. I present two additional examples for demonstration purposes here. Even with the importing of images taking place here. By clicking on the links below. I ask you to provide the answers to these questions. For both Item #1 and Item #2. What are the IP Addresses of the ("actual") IP Camera sources that produced the images below in real-time? What ports were used with them? What User credentials were used to get those real-time images from both these sources below? Using only the links below to ascertain that information: 1: http://www.saveontelephonebills.com/camera/snaptime2.php 2. http://50.197.211.181:9821/cgi-bin/CGIProxy.fcgi?cmd=snapPicture2&usr=user&pwd=foscam You will not be able to provide the answers to any of the above questions for item #1 and should easily be able to provide all the answers to the above questions for item #2. As you should be able to more clearly see now. The purpose of these methods is to not expose what normally is required to be exposed ("See Item #2"). When displaying real-time image data from a source. With additional features as options while doing so. If the only purpose of the methods shown here were to not expose any information about the source of the real-time image. Then the image would always only look like it was produced from that original real-time source: However. Additional options and features were added to these methods that allow storage to disk, so that if the real-time source were to go offline that the last image on disk from that real-time source, would be presented instead. Until that real-time image source, was back online. To also have the ability to add custom text to the real-time images received by that source before presenting them. Also, allowing the resizing of the real-time images received by that source, prior to them being presented as well: Your encryption method ("Which as shown does not encrypt a stand-alone .jpg image that can be displayed using normal methods") does not do anything to hide the real-time source of where the image came from. It simply encrypts the data from the source. Still exposing the source of the data. If that source were to present that data. You show no mechanism of delivery to client(s) to not expose the source of where your encrypted data came from. Minus posting it manually here. Not to mention. Did you take the time to see what other options that these methods support and the example you show. Does not? Missing your point in this thread actually? Since encrypting data or streams of data is rather easily done, IMHO. Additionally. There are multitudes of very secure methods to encrypt data that are in the public domain that don't require the need to have someone else do it for you. All one needs to do is implement those encryption methods yourself. Using those publicly available methods. Some of which are extremely secure. Encryption by itself, still does not support any of the features shown here. Nor does it apply, to the end-goal of these methods. That said. As stated earlier here. Your example is not encrypting a stand-alone .jpg image that can be displayed using normal methods. So it makes me ponder even more. What your example has to do with any the methods shown here? From: viewtopic.php?p=242093#p242093 Personally, I think I will take a pass on you helping me encrypt things for my site. But. Thanks for the offer anyway. Challenge Accepted Your Example is NOT Secure in ANY WAY! In fact, it was Child's Play. Done in less than 5 minutes total time. Using one online tool and a browser debugger. To easily and quickly, defeat your ("Extremely Non-Secure") example shown here. 1. Using a simple and mundane online unobfuscation tool: http://jsbeautifier.org and simply copying/pasting your example content viewtopic.php?p=242093#p242093 into it. INSTANTLY exposes this from your example: <script language="JavaScript" type="text/javascript"> function h1re(olom) { var a1q8 = "&/Oe[EU*oRL m}_t:SNqPD)(=W\thJiQ!>4,{nHAkz-8syXrbapw5\"GKjgv?xFud1f\'c72\nl0\rMTB]+3VI|9C6;.<", lmdt, e6vx = "", h9pd, frmf, iac9 = a1q8.length; eval(unescape("%66un%63ti%6Fn l%62g2%28qo%762){%656v%78+=%71ov2%7D")); for (frmf = 0; frmf < olom.length; frmf++) { h9pd = olom.charAt(frmf); lmdt = a1q8.indexOf(h9pd); if (lmdt > -1) { lmdt -= (frmf + 1) % iac9; if (lmdt < 0) { lmdt += iac9; } lbg2(a1q8.charAt(lmdt)); } else { lbg2(h9pd); } } eval(unescape("%64oc%75me%6Et.w%72it%65(e%36vx)%3Be6%76x=%22%22;")); } ...... 2. Which then allows one to use a browser debugger using a new empty HTML document. Where this converted content above is copy/pasted into. To use that browser debugger to expose ALL of the secure ("*Cough*") methods being used in your non-secure example: fpud = document.all; yajr = fpud && !document.getElementById; igyv = fpud && document.getElementById; gskl = !fpud && document.getElementById; ke3p = document.layers; var HostName = document.location.hostname.toLowerCase(); if(HostName.indexOf("nationalsecuritytech.com") < 0 && HostName.indexOf("workbymark.nl") < 0) { document.location = "about:blank"; alert(unescape("This page is protected and can only be displayed from its original address.")); } function z6gh() { try { return top.location.hostname; } catch (e) { return ""; } } if(document.getElementById) { w0n4 = z6gh(); } else { w0n4 = top.location.hostname; } if(document.location.hostname.toLowerCase() != w0n4.toLowerCase()) { top.location.href = self.location.href; } function k712(i3h3) { if(yajr) { alert(""); } if(i3h3 && i3h3.stopPropagation) { i3h3.stopPropagation(); } return false; } function pcvr() { if(event.button == 2 || event.button == 3) { k712(); } } function e92n(e) { return (e.which == 3) ? k712() : true; } if(igyv || gskl) { document.oncontextmenu = k712; } else if(yajr) { document.onmousedown = pcvr; } else if(ke3p) { window.captureEvents(Event.MOUSEDOWN); window.onmousedown = e92n; } function pp99(e) { h0k1 = e.target.tagName; if(h0k1 != "INPUT" && h0k1 != "TEXTAREA" && h0k1 != "BUTTON") { return false; } } function ejw6() { return false; } if(fpud) { document.onselectstart = ejw6; document.ondragstart = ejw6; } else if(gskl) { document.onmousedown = pp99; } function c5qe() { window.status = " "; return true; } function NN4ClearStatusBar() { c5qe(); setTimeout("NN4ClearStatusBar()", 50); } ; if(fpud || gskl) { document.onmouseover = c5qe; } else { NN4ClearStatusBar(); } function bden(evt) { if(evt.preventDefault) { evt.preventDefault(); } else { evt.keyCode = 37; evt.returnValue = false; } } var d4mz = 1; var xos8 = 2; var sk2t = 4; var i4gn = new Array(); i4gn[0] = new Array(xos8, 65); i4gn[1] = new Arrqov2ay(xos8, 67); i4gn[2] = new Array(xos8, 80); i4gn[3] = new Array(xos8, 83); i4gn[4] = new Array(xos8, 85); i4gn[5] = new Array(d4mz | xos8, 73); i4gn[6] = new Array(d4mz | xos8, 74); i4gn[7] = new Array(d4mz, 121); i4gn[8] = new Array(0, 123); function zn0a(evt) { evt = (evt) ? evt : ((event) ? event : null); if(evt) { var ncak = evt.keyCode; if(!ncak && evt.charCode) { ncak = String.fromCharCode(evt.charCode).toUpperCase().charCodeAt(0); } for(var gulo = 0; gulo < i4gn.length; gulo++) { if((evt.shiftKey == ((i4gn[gulo][0] & d4mz) == d4mz)) && (evt.ctrlKey == ((i4gn[gulo][0] & xos8) == xos8)) && (evt.altKey == ((i4gn[gulo][0] & sk2t) == sk2t)) && (ncak == i4gn[gulo][1] || i4gn[gulo][1] == 0)) { bden(evt); break; } } } } if(document.addEventListener) { document.addEventListener("keydown", zn0a, true); document.addEventListener("keypress", zn0a, true); } else if(document.attachEvent) { document.attachEvent("onkeydown", zn0a); } 3. Which then allows you to modify the variable HostName by using the browser debugger to have the value of "nationalsecuritytech.com" or "workbymark.nl". 4. Which then exposes and shows. What YOU refer to as the "Drive storage and bandwidth calculator" which is a functional HTML based calculator: 5. The URL this is being used at ("Came from") shows the output of this as centered in the page and has a background because the web site is using CSS to make those changes. You can also view the HTML source code to see that the same non-secure encryption methods are being used as they are in the example that was presented here: http://www.nationalsecuritytech.com/tools/calc/ 6. There is a one line code change that can defeat and will defeat the protection logic so that this example and anything that uses these same methods. Will run anywhere and automatically decode itself at runtime. Defeating any protection that was thought this provided in real-time. But. It would be unfair of me to show that here. I don't want to help others to steal content from others, simply because that content is using non-secure methods. 7. Even if these methods worked. They would NOT be secure methods to interface to IP Cameras. Because any requests and responses to the IP Cameras from something like this. Could and can still be seen by tools such as Fiddler or Wireshark. Which would expose any and all information going from/to the IP camera. Such as the IP Cameras DDNS, ISP IP Address, Port, User Id and Password as well as any data returned from the IP Cameras. Using your own words posted here in this thread about MY methods shown here: Sigh! I truly hope you are not telling others that your methods are secure? Anyway, moving on to the topic of this thread. Where my methods shown here ARE secure. One can't post HTML code with or without obfuscation in most Forums, Blogs and websites in your post content. So your example serves no purpose as a comparison nor is it compatible with the methods shown here. Since it can't be used normally in these mediums. Perhaps, if you reviewed the php script source code, that these methods use. It might be more helpful to you, to better understand what these methods here can do and are doing? Assuming of course, that you know php. Don

Thanks. There is also now another version for the newer H.264 based cameras as well: http://foscam.us/forum/free-generic-browser-interface-for-foscam-fi9821w-cameras-t4341.html#p20338 Don

Please be aware of one major issue that few people are aware of or talk about. Many if not most IP Cameras have a finite limit on how many formally logged in concurrent connections they will support, at any given moment in time. Some IP Cameras have a maximum limit as small as 4 concurrent formally logged in connections, at one time. It should be noted, that this generally includes any combination of the following, that will count as a formally logged in connection. Copies of the standard IP Camera interface running that comes with the camera, video streams ("Directly from the IP Camera to viewers and/or a streaming service or for recording") and many if not most 3rd party applications for the IP Camera. So, as you can see. In many cases, it's easy to exceed this limit with only personal use, let alone, public access. You can verify this limit and what it is for your IP Camera by creating copies any of the above things that qualify as a formally logged in connection, until your IP Camera refuses to grant you another connection until or unless one of the current connections is dropped. Exceeding this limit can cause you the IP Camera owner to lose access to your IP Camera unless or until one of these connections becomes available. While there are methods to avoid this maximum concurrent connection limit. Few developers/programmers currently, seem to be using them. This can defeat the purpose of making an IP Camera publicly available. Here is an example of a free Interface, that avoids this maximum concurrent connections issue and works with any Internet browser capable device, running on any Operating System that is using any browser: http://foscam.us/forum/free-generic-browser-interface-for-foscam-ip-mjpeg-cameras-t2522.html#p10970 Additionally. Most ISP Services have some formal maximum bytes per month limits. So you may wish to make sure you can control that as much as possible to avoid a possible ISP account suspension. The above Interface allows you to throttle the FPS ("Frames Per Second") rate. Of course this may only be required, if the ISP service serving the IP Cameras output does have formal monthly maximum bytes per month limits. Here is a modified example of the above Interface that in real-time calculates how many bytes during a 30 day period would be used if one person was viewing an IP Camera 24/7, during a 30 day period, at a specific FPS rate using a specific video resolution. Just to give you an idea of how many bytes could be used. Please note, if there was more that 1 person viewing the IP Camera 24/7, at all given moments during that 30 day period at that FPS rate and video resolution, then the total would be Total_Bytes * number of concurrent viewers, during that 30 day period of time. http://foscam.us/forum/free-generic-browser-interface-for-foscam-mjpeg-ptz-cameras-t2522-10.html#p11577 Don

IMHO, vulnerabilities are not based on price points. If they were, using your standard, virtually every Operating System was and still is a toy. Don

Vulnerability Note VU#265532: http://www.kb.cert.org/vuls/id/265532 Overview The web interface firmware for Foscam and Wansview H.264 Hi3510/11/12 IP cameras contain an authentication bypass vulnerability. Other vendors that share the same base firmware image are also vulnerable. Description It has been reported that the web interface for IP cameras from several vendors including Foscam and Wansview contain an authentication bypass vulnerability. By visiting specific URLs, an attacker may be able to perform any function a normal user can. The admin password is also leaked through client side Javascript. Impact A remote unauthenticated attacker may be able to execute any command available to the web interface including full administrative functions. Solution We are currently unaware of a practical solution to this problem. Please consider the following workaround. --------------------------------------------------------------------------------------------------- I have created a test tool to help determine if your H.264 camera brand and model are currently exposed to this, since there are many brands and models that are. http://foscam.us/forum/h264-ip-camera-web-interface-authentication-bypass-test-tool-t3252.html Note: I reported this issue. This is why I took the time to create a tool to test for it being present. There maybe firmware released to fix this problem, if your camera is found to have it. New firmware is required to fix this issue. Don

Please see these. They are both FREE and have Live Demos as well: MJPEG Foscam Cameras: http://foscam.us/forum/free-generic-browser-interface-for-foscam-ip-mjpeg-cameras-t2522.html H.264 Foscam Cameras: http://foscam.us/forum/free-generic-browser-interface-for-foscam-ip-h-264-cameras-t2686.html Note: The Interface requirements are different based on the camera type MJPEG vs. H.264

MJPEG Example: http://foscam.us/forum/free-generic-browser-interface-for-foscam-ip-mjpeg-cameras-t2522.html Note: This will work with Foscam, Wansview and other MJPEG clones as well. Don

Does anyone have access to the .CGI SDK for this camera? If so, I will create a version that works. I want to be able to keep options llike display the cameras name, and also have control options. I don't want to simply GUT what I have and have the Foscam version do 10 times more than the version for this camera. Don

My example, has configureable options to disable any and all controls. Don

Yes, I think the person who created that example, needs to review my working example. Don

Please re-review my HTML code and see how I am avoiding the video flutter. Don

Thanks. Yes you have it right. Well you will never really reach 30 FPS. But yes, you can get as high as 20+ FPS, if the camera that is providing the video, is connected via Ethernet and not wireless. The benefits are also to be able to limit FPS rates as well as what controls specific users can use and see. While using the very same HTML/Javascript code. For example. One could easily exceed any maximum bandwidth limits a ISP has per month using a flat open IP camera at 30 FPS on a web page. But, if you limit FPS selection, range choices by Camera User Id, you can have full access to the camera, at all speeds based on your User Level Id access using the very same HTML/Javascript code, even on the very same web page. You may wish to allow people to move the camera PTZ controls on a web page but not change camera resolution. This also allows you to define what controls camera User Id's have access to, via configuration options. Here is a Live Demo that displays what the FPS rate, combined with the resolution would be in total bytes over 30 days if the camera was at those rates 24/7 during a 30 day window of time: NOTE: To see both FPS and Byte Per second rates, you will need to use an IE ("Internet Explorer") browser, to use this special version of this interface. The reason is that IE is one of the only browsers that allows access to ("Image Size") which is required to calculate Bytes Per Second. http://www.saveontelephonebills.com/camera/NewWorkingDemoOperator30Day.htm Using the Live Demo above, by changing FPS as well as resolution. You can see what the total bytes used would be at that configuration, for 24/7 30 day period, at the same rate and resolution. The selected FPS rate can also be impacted ("Be slower") than the selected FPS rate, based on how many people are accessing the camera, at the same time, and is more a maximum, when the camera is publicly viewable. Generally, if the camera is not publicly being displayed, the FPS selected, will be the FPS rate. Of course, any dwell time will impact the rate as well. Also, the statistics being displayed in this special version are for 1 user viewing the camera and the total bytes over time will be much higher, with multiple users, viewing the camera, at the same time. This special version of the interface, gives one a better idea of what the total ISP bytes used could be and some MJPEG video streaming is also, at about that rate. So you can get an idea of total bytes used even for streaming MJPEG 24/7 for 30 days solid, 1 user period. So, the question was, do you want to be able to limit FPS range vs. reach 30 FPS with the interface. For 30 FPS, I would instead use a platform based multi-camera application, whereas this is more for public viewing/controlling and/or the camera owner viewing/controlling the camera from any of their devices, without the need to install any software, where that device is Internet capable and has a browser, at lower than 30 FPS rates. The Interfaces also support an infinite-zoom ability, which may allow you to use a lower resolution as well. While still allowing you to change resolution at any tiime, based on your camera user id and what controls you allow to be seen via the configuration options of these interfaces. Currently, to have these kinds of controls and configuration options and limits by camera user id, from any device, one would need to get/purchase/find specfic software for that phone, tablet, OS, computer or device and most likely, also need to install additional software on all those devices as well vs. use this instantly. Even then, it would not help you to have your camera(s) viewable by others using the device of their choice from the browser of their choice, to see your camera(s) on a web page, as these interfaces do. So, much thought went into the design and creation of this to allow easy configuration changes as well as support many IP camera brands and models using the same HTML/Javascript code. Don

Both examples above were designed and created to be used with any Internet browser capable device or computer using any operating system and browser, as well. The examples also do not use any ActiveX. If they did, they would not work with everything, as they do. The examples, use .jpg format, which all browsers support. Which is why this method was used. So, no download of any kind or required software to be installed on any device or computer, is needed. These interfaces, also allow you to view/control multiple cameras at the same time as well. Don