Important Message from Foscam Digital Technologies Regarding US Sales & Service



We, Foscam.US (aka Foscam Digital Technologies and now Amcrest Technologies), are an independent United States based distributor of "Foscam" branded products. We have been offering telephone support, US local warranty and building the Foscam brand in the US for the past 7 years. However, we are deeply saddened to report that, even after all of this, our overseas suppliers have decided to undercut us and supply to our major customers directly. For this reason, we have no choice but to suspend telephone support for all Foscam branded products. If you have purchased a Foscam camera directly from us or from one of our authorized retailers, technical support is still available via email at support@foscam.us.


For customers who have not purchased from us directly, we advise you to please contact Foscam Shenzhen or the distributor which you have purchased from. In the meantime, we have launched our own new brand of IP cameras called Amcrest, which has superior quality products and full telephone technical support 7 days per week. We hope you can support us in our new venture. For more information, please visit www.Amcrest.com.



A How To Embed Any Foscam IP Camera In Webpage Using 1 Line

General discussion regarding Foscam IP Cameras

A How To Embed Any Foscam IP Camera In Webpage Using 1 Line

Postby TheUberOverLord » Mon Mar 24, 2014 5:10 am

Any IP Camera owner can optionally easily get and use All my Foscam IP Camera examples bundled together with one hour of one-on-one support to implement them. Save Time! Click Here!

For the full list of live demo IP Cameras. Please click the link below:

http://107.170.59.150

Image sizes for the examples shown here are small for demonstration purposes. You can use any sizes.

Many people have asked for ways to embed their Foscam IP Cameras in webpages having the images from their cameras refresh automatically. Here is a way to do it using one line in a HTML file. Some things need to be explained and a working example is also provided.

Works with ANY IP Camera
Image
Accessible From ANY Computer, Laptop, Tablet, Phone and TV

If you don't already have a website or a web server to host things like this or to store your IP Cameras Snapshot images and/or videos via FTP. All the examples here are hosted by DigitalOcean which I have found to have great prices and support. No domain name is required and you get your own unique IP Address and it's your Web Server, NOT shared!
Click for more details

You can add as many Foscam IP Cameras as needed on the same webpage each only requiring 1 line of HTML code per IP Camera.

Note: Some demo IP Cameras can be down at times. Which I have no control over. If you see nothing using a link for an example here. Please try another IP Camera example link here. There are many different demo IP Cameras and examples here.

These methods allow you to even create automatically refreshed real-time thumbnail images vs. static thumbnail images that can be clickable or not. Example using 14 different IP Cameras at the same time:

http://107.170.59.150/foscam/FoscamUS.htm

The working example below is using a small image size for demonstration purposes but you can use any image size.

Here is the one line needed in the webpage:

Code: Select all
<img src="YourIPCamInfo&t=" width='' onload='setTimeout(function() {src = src.substring(0, (src.lastIndexOf("t=")+2))+(new Date()).getTime()}, 1000)' onerror='setTimeout(function() {src = src.substring(0, (src.lastIndexOf("t=")+2))+(new Date()).getTime()}, 5000)' alt='' />

Example lines using the above for both MJPEG and H.264 Based Foscam IP Cameras:

MJPEG Based Foscam IP Camera:

Code: Select all
<img src="http://DDNSorISPIPAddress:PortForCamera/snapshot.cgi?user=CameraVisitorId&pwd=YourPassword&t=" onload='setTimeout(function() {src = src.substring(0, (src.lastIndexOf("t=")+2))+(new Date()).getTime()}, 1000)' onerror='setTimeout(function() {src = src.substring(0, (src.lastIndexOf("t=")+2))+(new Date()).getTime()}, 5000)' alt='' />

H.264 Based Foscam IP Camera:

Code: Select all
<img src="http://DDNSorISPIPAddress:PortForCamera/CGIProxy.fcgi?cmd=snapPicture2&usr=CameraVisitorId&pwd=YourPassword&t=" onload='setTimeout(function() {src = src.substring(0, (src.lastIndexOf("t=")+2))+(new Date()).getTime()}, 1000)' onerror='setTimeout(function() {src = src.substring(0, (src.lastIndexOf("t=")+2))+(new Date()).getTime()}, 5000)' alt='' />

Note: Replace the DDNS or IP Address and Port above as well as the CameraVisitorId and YourPassword with valid Foscam IP Camera User Id and their password and leave the &t= at the end before the double quotes.

You can also add text in the alt='' tag like alt='MyIPCam' as an example. So that when people hover their mouse over the image of your camera they see a name.

Additionally. If you notice in the first example there is a width='' statement. You can add width='640' for example if your IP Cameras image by default is large to control the size displayed with any value you wish while keeping the aspect ratio height of your IP Cameras image if needed.

It's suggested to create a visitor User Id for your Foscam IP camera when doing this. So that nobody could use the User Id and Password used to move your camera. Such as an Operator User Level Id. For sure, please NEVER use an Admin User Level Id for your Foscam IP Camera for anything that will be public.

The value of 1000 represents the refresh rate which is 1000 Milliseconds which equals 1 second. If you want your Foscam IP Camera to refresh more or less often then please change 1000 to the value of your choice.

The value of 5000 represents how often an attempt should be made to refresh when there is an error which also is in Milliseconds which equals 5 seconds. If you want to retry refreshes that fail sooner or later then please change 5000 to the value of your choice.

Working Example ("Which has a 2 minute limit for demonstration purposes included") using a MJPEG based Foscam IP Camera:

http://107.170.59.150/V31/EmbedIPCameraInWebPageOneLine.htm

Working Examples with Infinite Zoom Features Added:

http://107.170.59.150/foscam/GlobalZoomExample.htm

Just because you define a default width. Does not mean you can't change resolutions on the fly. When and as needed. This is an internal zoom feature that is not changing the actual cameras resolutions but only for that browser window and the person viewing that browser window.

The above methods are NOT secure methods when used by themselves. Meaning that they expose the DDNS and/or IP Address location and Port of your Foscam IP Camera and a User Id and Password for your Foscam IP Camera. The same methods can be done securely as well. In fact the working examples shown here are using the secure methods combined with these methods.

Please see this for those methods:

http://foscam.us/forum/showing-secure-methods-using-php-to-display-your-ip-cameras-t8721.html#p42139

Don
TheUberOverLord
 
Posts: 13105
Joined: Fri Jun 22, 2012 11:52 pm

Re: A How To Embed Any Foscam IP Camera In Webpage Using 1 L

Postby klaipedaville » Fri Apr 11, 2014 1:39 pm

Hey Don!

These instructions are real nice.

However, I was wondering is it somehow possible to use jw player or flowplayer or just embed any other players (not necessarily flash) to see a better movie?

Not sure if I am on the right track here but my IP camera's movie / live stream sometimes "jumps". The motion does not flow nicely as in movies on TV for example, it jumps instead, then stops for a second, then jumps again and stops for a second again. Javascript actually sets how often the picture is changed (1000 milliseconds) but it is still the picture, not the movie like in players, that's why I get these jumping effects, is that not right is it?

Would appreciate any comments/ assistance / help at all. Many thanks!
klaipedaville
 
Posts: 7
Joined: Mon Nov 25, 2013 2:25 pm

Re: A How To Embed Any Foscam IP Camera In Webpage Using 1 L

Postby TheUberOverLord » Fri Apr 11, 2014 2:30 pm

klaipedaville wrote:Hey Don!

These instructions are real nice.

However, I was wondering is it somehow possible to use jw player or flowplayer or just embed any other players (not necessarily flash) to see a better movie?

Not sure if I am on the right track here but my IP camera's movie / live stream sometimes "jumps". The motion does not flow nicely as in movies on TV for example, it jumps instead, then stops for a second, then jumps again and stops for a second again. Javascript actually sets how often the picture is changed (1000 milliseconds) but it is still the picture, not the movie like in players, that's why I get these jumping effects, is that not right is it?

Would appreciate any comments/ assistance / help at all. Many thanks!

You are very welcome.

The issues with using a Live video streaming vs. refreshed Snapshots is four fold:

1. ("Live") Video Streaming is not supported by every Internet browser capable device. Even when a device can support Live Video Streaming it may require the user of that device to install additional software before they can view your IP Camera. Will they do that if needed?

What's are your end-goals of displaying your IP Camera in a webpage?

If it includes not being able to allow any/all Internet browser capable devices to view your IP Camera and you care little, that additional software by the viewer maybe required to be installed first before being able to see your IP Camera. Then maybe Live Video streaming is the way to go if you can deal with the additional issues below as well.

If your IP Camera is in wireless mode and you are allowing direct access to the IP Camera to pull Live Streaming Video. You also need to have the wireless bandwidth to support those connections at the same time. If your wireless network has any contention issues with nearby wireless networks or your cameras wireless signal is very weak to the Router/AP then this can be very complicated to do because wireless packets can be re-transmitted when they are garbled and cause much more wireless bandwidth to be required than normal. More here about that:

post15934.html#p15934

2. Virtually ALL IP Cameras have a finite limit of concurrent Long-Term connections. Long-Term connections include copies of the standard IP Camera Interfaces that are running and logged in to a specific IP Camera, Direct Video Streams to that specific IP Camera and third-party software which logs into your IP Camera and stays logged in, until that application is stopped.

This finite limit of maximum concurrent Long-Term Connections can be as few as Four concurrent connections.

When this limit is reached. You the IP Camera owner will NOT be able to logon to your camera. Effectively locking you out of access to your IP Camera. Unless/Until one of those Long-Term connections can be freed up, you use a CGI command to reboot the camera or you go to the IP Camera location to power down/up the IP Camera.

You can easily emulate and create this situation yourself. To see it with your own eyes. By simply opening, as an example, four different browser windows and accessing your IP Cameras standard camera Interface and logging into each one. Then try doing the same using a fifth browser window.

3. Live Video Streaming bandwidth can easily exceed your ISPs monthly bandwidth limits when you provide Live Video Streams directly from your IP Camera. Your ISP may suspend your account for the remaining portion of the month or add additional charges when this happens.

There are Video Streaming services which can act as a Video Streaming server for your IP Camera so that there is only one Long-Term connection required to be in use when streaming Live video from your IP Camera to others. But most have costs or cutoffs when more then ("x") bandwidth or concurrent connections are used and required.

4. It's NEVER a good idea to publicly expose the DDNS or ISP IP Address and Port and ANY User credentials for your IP Cameras. Because it allows anyone to create the situation shown in #2 above.

The examples shown below are using secure methods to display a single and refreshed images from your IP Camera where no camera information is ever exposed. More here:

showing-secure-methods-using-php-to-display-your-ip-cameras-t8721.html#p42139

Whereas. Refreshed Snapshots from your IP camera can be controlled securely and as to the rate of the refreshed images to better control bandwidth and this method uses what are referred to as "Short-Term" connections so this finite limit is no longer as small as four as the Long-Term concurrent limits can be and is about 100 concurrent "Short-Term" connections with a refresh rate of 1 image per second. Larger as the refresh delay rate gets longer.

The ("actual") Short-Term concurrent connection limit is 80. But it really does not apply in most cases. Because it applies to outstanding/in progress/in flight requests not yet responded to.

So at any give moment of time 80 of 80 possible concurrent Short-Term connections. Most likely would not be in progress/in flight, at the same time and not yet responded to with a 1 second delay between refreshed images. Which is why I say 100 as a maximum vs. 80 for a 1 second image refresh delay.

This is because these "Short-Term" connections are automatically and immediately closed as soon as the Snapshot has been delivered to the viewers browser.

Even if you were to reach this 100 concurrent connection limit for Short-Term connections. It has no cause or effect on your ability to use a Long-Term connection to access your IP Camera when and if that were to take place. So using refreshed image methods will never cause you to be locked out of accessing your own IP Camera.

The most important aspect of using the refreshed Snapshot methods besides not locking yourself out of being able to access your own IP Camera and the ability to support far more concurrent connections to the IP camera.

Is that refreshed images are supported by any and all Internet browser capable devices. From Computers to Laptops and Phones to TVs. There is never any requirement by anyone to ever install any additional software in order to view your IP Cameras on any device. As in ever.

Additionally. By using refreshed images. You can use a single image of your IP Camera that only when clicked causes refreshed images to be displayed. Still allowing visitors of your webpage to see a current real-time single image of your IP Camera and then deciding if they want to see more. Saving you potentially lots of bandwidth vs. defaulting to Live Video streaming right away.

Example:

If I simply had a clickable link in a web page that said.

Click to view my IP Camera now

Most likely. Many people would click on the link above. Because they have no idea of what they will see.

Please note the images used in the examples are small for demonstration purposes and can be any size.

However. If I had a single and current real-time image of the IP Camera in question displayed on that same web page.

The image below is a current real-time image from a Foscam Demo camera when you loaded this web page. NOT when I created my response post to you:

Image

Click on the image above or this link to view my IP Camera now

If nothing is currently going in the above image that intrigues the specific viewer. Maybe some of them would not click the link above vs. the first example. Saving you lots of web server bandwidth and resources.

Also helping you to more avoid the Short-Term concurrent connection limit of 100 at 1 second image refresh intervals by having more people who really do wish to see your IP Camera vs. those who were simply curious on what they will see when no current real-time image is displayed and only a link to view your IP Camera.

Of course the clickable example links above are using secure refreshed images vs. Live streaming video as well.

Don
TheUberOverLord
 
Posts: 13105
Joined: Fri Jun 22, 2012 11:52 pm

Re: A How To Embed Any Foscam IP Camera In Webpage Using 1 L

Postby klaipedaville » Sun Apr 13, 2014 4:13 am

Thank you so much for sharing, Don! Your information is so comprehensive! It's been very interesting to read.

Let me also respond with my comments and findings. It took me some time to go through your big post and test and try a few things.

My goal was just to stream my video for fun so that everybody would be able to come see it online. It's like TV stations do, or weather webcams or any other amateur webcams that simply broadcast live interesting, famous or any other places with a lot of people, movement and so on.

I have it working fine but as you said my concurrent connections are limited both long-term and short-term but let me go by your points first.

1. JavaScript code is normally supported by any devices nowadays (that is what your code is written in) whereas various players, x controls, add-ons, add-ins, etc., usually take a minute to install and right you are here on the fact that it depends on users' preferences. On the other hand flash players are built-in in a lot of browsers and Adobe for example even updates its flash player in the background so that its end users do not even know that something is going on behind the scenes. That's why as soon as a video in a flash format is detected it starts playing without any need to download or install anything extra. I have this method working on my website as well. The recorded video in the flash format is playing fine without any limits on concurrent connections. It even uses a player installed on the same website (same host) so my viewers do not even need to download / install anything extra at all on absolutely any devices or browsers. The difference is that this is a recording when my current task (attempt) is to do so with a live video streaming.

My wireless bandwidth connections are unlimited.

2. Yes, you are right here. My concurrent long-term connections are limited to 5. I have tested it as per your advise.

3. My ISP bandwidth is also unlimited. The internet connection is 100/100 and I am fee to use it as much and as long as I want / need.

4. I do not use admin login details as this would be silly, I use visitor's login details (created by me) which of course disposes my ISP's IP but it has no control over streaming. It just broadcasts the streaming itself. It would be great to hide even my ISPs' IP and my visitors' login details as per your PHP scripts or write my own scripts as this PHP task is pretty simple and straight forward but first I need to get it working with unlimited concurrent connections or via players that could in turn provide these unlimited concurrent connections by default.

On a side note I also thought of a more complicated way to have it done. I get my live video streams recorded first, then convert them into flash and then broadcast them live. All these 3 steps would be performed automatically in code and alternate one after another. Stream, record, convert, broadcast, change. Stream, record, convert, broadcast, change. Repeat. Rotate the logs on my server and keep only 10 latest days of recordings to save on space / room.

Now as for short-term connections in Javascript with shapshots. I think the short-term connections are limited the same way as they are limited with the long-term connections. The following test was performed. I opened six tabs in my browser and got myself locked out even though the js code with short-term snapshots was the only code inside these 6 tabs.

Here is your code used for testing:

<img src="http://IPaddress:port/snapshot.cgi?&user=user&pwd=password&t=" onload='setTimeout(function() {src = src.substring(0, (src.lastIndexOf("t=")+2))+(new Date()).getTime()}, 1000)' onerror='setTimeout(function() {src = src.substring(0, (src.lastIndexOf("t=")+2))+(new Date()).getTime()}, 1000)' alt='Live Cam' />

here is my js reload function used for testing:

<script language="JavaScript" type="text/javascript">
function reload()
{
setTimeout('reloadImg("refresh")',1000)
};
function reloadImg(id)
{
var obj = document.getElementById(id);
var date = new Date();
obj.src = "http://IPaddress:port/snapshot.cgi?user=user&pwd=password&t=" + Math.floor(date.getTime()/1000);
}
</script>
<img src="http://IPaddress:port/snapshot.cgi?user=user&pwd=password&t=" name="refresh" id="refresh" onload='reload(this)' onerror='reload(this)'>

In both codes connections were not automatically and immediately closed as soon as the snapshots had been delivered to viewers. Otherwise I wouldn't have been locked out on my 6th connection. Could you please, comment on that? It looks like I am limited to 5 concurrent connections only no matter what type they are, short-term, long-term, medium-term, etc.

Both js codes work fine and do live-stream but allow only limited concurrent connections despite the fact that they are short-term refreshed snapshots.

I still do not quite get it as my main question was concerned, would it be generally possible to use any players (jw player, flowplayer, etc.) to live-stream from my IP camera on http protocol only and not on rtsp and rtmp? Any more suggestions / advices? Many thanks!
klaipedaville
 
Posts: 7
Joined: Mon Nov 25, 2013 2:25 pm

Re: A How To Embed Any Foscam IP Camera In Webpage Using 1 L

Postby rubyreddevon » Sun Apr 13, 2014 5:06 am

Very many thanks for this Don. I've struggled with this streaming issue for a long time and was near to despair. Now you have explained it beautifully and my camera's are working well with your html.

I tried your generic interface with my F19085W but couldn't get any results. I'll persist and report any progress.

Happy Days

See here:

http://www.littleham-landcross.org.uk
rubyreddevon
 
Posts: 1
Joined: Sun Apr 13, 2014 4:59 am

Re: A How To Embed Any Foscam IP Camera In Webpage Using 1 L

Postby TheUberOverLord » Sun Apr 13, 2014 7:52 am

klaipedaville wrote:Thank you so much for sharing, Don! Your information is so comprehensive! It's been very interesting to read.

Let me also respond with my comments and findings. It took me some time to go through your big post and test and try a few things.

My goal was just to stream my video for fun so that everybody would be able to come see it online. It's like TV stations do, or weather webcams or any other amateur webcams that simply broadcast live interesting, famous or any other places with a lot of people, movement and so on.

I have it working fine but as you said my concurrent connections are limited both long-term and short-term but let me go by your points first.

1. JavaScript code is normally supported by any devices nowadays (that is what your code is written in) whereas various players, x controls, add-ons, add-ins, etc., usually take a minute to install and right you are here on the fact that it depends on users' preferences. On the other hand flash players are built-in in a lot of browsers and Adobe for example even updates its flash player in the background so that its end users do not even know that something is going on behind the scenes. That's why as soon as a video in a flash format is detected it starts playing without any need to download or install anything extra. I have this method working on my website as well. The recorded video in the flash format is playing fine without any limits on concurrent connections. It even uses a player installed on the same website (same host) so my viewers do not even need to download / install anything extra at all on absolutely any devices or browsers. The difference is that this is a recording when my current task (attempt) is to do so with a live video streaming.

My wireless bandwidth connections are unlimited.

2. Yes, you are right here. My concurrent long-term connections are limited to 5. I have tested it as per your advise.

3. My ISP bandwidth is also unlimited. The internet connection is 100/100 and I am fee to use it as much and as long as I want / need.

4. I do not use admin login details as this would be silly, I use visitor's login details (created by me) which of course disposes my ISP's IP but it has no control over streaming. It just broadcasts the streaming itself. It would be great to hide even my ISPs' IP and my visitors' login details as per your PHP scripts or write my own scripts as this PHP task is pretty simple and straight forward but first I need to get it working with unlimited concurrent connections or via players that could in turn provide these unlimited concurrent connections by default.

On a side note I also thought of a more complicated way to have it done. I get my live video streams recorded first, then convert them into flash and then broadcast them live. All these 3 steps would be performed automatically in code and alternate one after another. Stream, record, convert, broadcast, change. Stream, record, convert, broadcast, change. Repeat. Rotate the logs on my server and keep only 10 latest days of recordings to save on space / room.

Now as for short-term connections in Javascript with shapshots. I think the short-term connections are limited the same way as they are limited with the long-term connections. The following test was performed. I opened six tabs in my browser and got myself locked out even though the js code with short-term snapshots was the only code inside these 6 tabs.

Here is your code used for testing:

<img src="http://IPaddress:port/snapshot.cgi?&user=user&pwd=password&t=" onload='setTimeout(function() {src = src.substring(0, (src.lastIndexOf("t=")+2))+(new Date()).getTime()}, 1000)' onerror='setTimeout(function() {src = src.substring(0, (src.lastIndexOf("t=")+2))+(new Date()).getTime()}, 1000)' alt='Live Cam' />

here is my js reload function used for testing:

<script language="JavaScript" type="text/javascript">
function reload()
{
setTimeout('reloadImg("refresh")',1000)
};
function reloadImg(id)
{
var obj = document.getElementById(id);
var date = new Date();
obj.src = "http://IPaddress:port/snapshot.cgi?user=user&pwd=password&t=" + Math.floor(date.getTime()/1000);
}
</script>
<img src="http://IPaddress:port/snapshot.cgi?user=user&pwd=password&t=" name="refresh" id="refresh" onload='reload(this)' onerror='reload(this)'>

In both codes connections were not automatically and immediately closed as soon as the snapshots had been delivered to viewers. Otherwise I wouldn't have been locked out on my 6th connection. Could you please, comment on that? It looks like I am limited to 5 concurrent connections only no matter what type they are, short-term, long-term, medium-term, etc.

Both js codes work fine and do live-stream but allow only limited concurrent connections despite the fact that they are short-term refreshed snapshots.

I still do not quite get it as my main question was concerned, would it be generally possible to use any players (jw player, flowplayer, etc.) to live-stream from my IP camera on http protocol only and not on rtsp and rtmp? Any more suggestions / advices? Many thanks!

You are very welcome.

1. Yes that's the issue. There is a difference on how most devices treat live video vs. recorded video.

This is because playing recorded video is more like a file transfer, you know where the video begins and ends and the other is streaming and has no beginning and potentially no end.

A good way to look at it is FTP. FTP allows you to transfer a file. But...the file must be complete not a file that has no beginning or end as of yet. In other words. You can FTP a video recording but you can't FTP a video stream because it has no beginning and has no current end.

While flash players may install without human intervention ("In some cases on some devices"). Not all devices support Flash and as time moves forward fewer devices will. So when I look at ("Any") browser capable device, I truly mean ("Any") browser capable device. From Computers/Laptops to Tablets and Phones to TVs. Which are running on any Operating System and using any browser.

More here about the ongoing demise of Flash and the current lack of any common standard across devices that can currently support live video:

http://blog.zencoder.com/2013/09/13/wha ... ml5-video/

2. Not sure why you need/require any js reload function to test your theory. Which I show using a working example below. Is not a correct one. Your testing methods are also giving your false results.

The img src = HTML line of code, is in fact doing the reload based on the value of 1000 Milliseconds ("1 Second") in the example code.

Therefore, you simply need to copy the img src = line for as many concurrent connections you wish to test for the same IP Camera.

Here is a example of using 12 Short-Term connections at the same time, with the same IP Camera, using a 1 second refresh rate. As you can see, it works fine.

I could have made it more then 12, But it gets the point across that the ("actual maximum") Short-Term concurrent conection limit is really 80. But that's 80 requests in progress/in flight/not responded to at any given moment in time.

http://107.170.59.150/short.htm

You can use free tools like Fiddler2, to in fact verify that the Short-Term Snapshot requests are not being rejected/denied and that in fact these Short-Term requests are automatically and immediately closed after the browser has received the Snapshot as well:

All 12 Concurrent Snapshot Requests Processed No Errors
Image

Connection Is Closed After Browser Receives Snapshot
Image

Please note that the total turn-around and processing time for the request above, was less then 1/2 a second which included adding the Date & Time and other text to the image after the image was received from the IP Camera. Without doing that extra work, it would have been much faster.

I say 100 is the virtual maximum Short-Term connection limit at 1 second refresh interval rates and the virtual Short-Term connection maximum limit becomes greater, with longer refresh delays.

This is because fewer Snapshot requests are in progress/in flight/not responded to at any same given moment of time, as the refresh delay becomes longer and longer.

As a example:

Even with the maximum of 80 ("actual") concurrent Short-Term connections being the maximum before any new Short-Term connection requests are refused/denied. If your refresh rate had a 5 second delay between images for each viewer being refreshed.

It's fair to say that half or less of those connections would have a Short-Term request actually in progress at the same moments of time.

Allowing you to most likely be able to support as many or more then 125 individual viewers during that 5 second window period. Without denying any of their requests.

You can benchmark this, using the methods shown above with your IP Camera setup to verify where about this maximum is currently for your IP Camera with your current setup. You can try different tweaks to make your IP Camera more efficient and responsive and increase that number as well. More here:

post15934.html#p15934

Note: For better emulation of this you will want to add/delete some small amount of Milliseconds for each individual HTML line that you add, so that they all don't fire image refreshes at the same exact moments in time to better emulate actual viewers starting to view the IP Camera at not exactly the same times.

The most important point I can make as a response to you here is that using a "Visitor" level IP Camera User Id ("In the clear") still cannot save you from anyone who wishes to use that Visitor User Id and Password exposed in the clear, with your DDNS and/or IP Address and Port for the IP Camera.

Because all one anywhere in the world would need to do at anytime is to logon using that "Visitor" User Id and password 5 times, using the Standard IP Camera Interface that comes with the IP Camera and you the IP Camera owner would NOT be able to logon to your own IP Camera unless:

a. They stopped.
b. You sent a CGI command to the IP Camera to Reboot your IP Camera.
c. You went to the IP Cameras location and powered the IP Camera Down/UP.

Note: A creative person ("Using JavaScript as one example") could even create enough Short-Term concurrent connections as well to block others from being able to get Snapshots from your IP Camera. So basically, your IP Camera would be inaccessible by you the IP Camera owner as well as anyone else.

If someone did this right. You might NOT even be able to issue a CGI reboot command for your IP Camera because it requires a Short-Term connection to do that. Meaning now your only option would be to go to the IP Cameras location and power down/up the IP Camera.

Worse. If they continue to do this. You will need to again, each and every time, to go to your IP Cameras location and power down/up to the IP Camera.

This is because this is the only way to KILL the current connections to the IP Camera.

But....if they don't stop. Then as soon as your IP Camera is powered on and reboots. They will make new connections and do the same for as long as they please.

Whereas. When using the secure methods combined with this method. Nobody knows the DDNS or IP Address or User credentials of your IP Camera to play these games. As in Ever.

Point being that whatever IP Camera information you expose to the public can be abused.

This is why IMHO. It's never a good idea to expose any of your IP Camera information publicly. As stated here. The method shown here can be used securely, not only insecurely. In fact, all the working examples shown here are using this method, combined with the secure methods.

Don
TheUberOverLord
 
Posts: 13105
Joined: Fri Jun 22, 2012 11:52 pm

Re: A How To Embed Any Foscam IP Camera In Webpage Using 1 L

Postby TheUberOverLord » Sun Apr 13, 2014 8:05 am

rubyreddevon wrote:Very many thanks for this Don. I've struggled with this streaming issue for a long time and was near to despair. Now you have explained it beautifully and my camera's are working well with your html.

I tried your generic interface with my F19085W but couldn't get any results. I'll persist and report any progress.

Happy Days

See here:

http://www.littleham-landcross.org.uk

You are very welcome.

Please make sure you are using the correct version there is a MJPEG version and a H.264 version of the Interface. Here is the one you want for your camera:

post20338.html#p20338

Note: There is a Live Demo of a FI9805W using the Interface there as well.

Don
TheUberOverLord
 
Posts: 13105
Joined: Fri Jun 22, 2012 11:52 pm

Re: A How To Embed Any Foscam IP Camera In Webpage Using 1 L

Postby klaipedaville » Mon Apr 14, 2014 12:58 pm

TheUberOverLord wrote:You are very welcome.

1. Yes that's the issue. There is a difference on how most devices treat live video vs. recorded video.

This is because playing recorded video is more like a file transfer, you know where the video begins and ends and the other is streaming and has no beginning and potentially no end.

A good way to look at it is FTP. FTP allows you to transfer a file. But...the file must be complete not a file that has no beginning or end as of yet. In other words. You can FTP a video recording but you can't FTP a video stream because it has no beginning and has no current end.

While flash players may install without human intervention ("In some cases on some devices"). Not all devices support Flash and as time moves forward fewer devices will. So when I look at ("Any") browser capable device, I truly mean ("Any") browser capable device. From Computers/Laptops to Tablets and Phones to TVs. Which are running on any Operating System and using any browser.

More here about the ongoing demise of Flash and the current lack of any common standard across devices that can currently support live video:

http://blog.zencoder.com/2013/09/13/wha ... ml5-video/

2. Not sure why you need/require any js reload function to test your theory. Which I show using a working example below. Is not a correct one. Your testing methods are also giving your false results.

The img src = HTML line of code, is in fact doing the reload based on the value of 1000 Milliseconds ("1 Second") in the example code.

Therefore, you simply need to copy the img src = line for as many concurrent connections you wish to test for the same IP Camera.

Here is a example of using 12 Short-Term connections at the same time, with the same IP Camera, using a 1 second refresh rate. As you can see, it works fine.

I could have made it more then 12, But it gets the point across that the ("actual maximum") Short-Term concurrent conection limit is really 80. But that's 80 requests in progress/in flight/not responded to at any given moment in time.

http://107.170.59.150/short.htm

You can use free tools like Fiddler2, to in fact verify that the Short-Term Snapshot requests are not being rejected/denied and that in fact these Short-Term requests are automatically and immediately closed after the browser has received the Snapshot as well:

All 12 Concurrent Snapshot Requests Processed No Errors
Image

Connection Is Closed After Browser Receives Snapshot
Image

Please note that the total turn-around and processing time for the request above, was less then 1/2 a second which included adding the Date & Time and other text to the image after the image was received from the IP Camera. Without doing that extra work, it would have been much faster.

I say 100 is the virtual maximum Short-Term connection limit at 1 second refresh interval rates and the virtual Short-Term connection maximum limit becomes greater, with longer refresh delays.

This is because fewer Snapshot requests are in progress/in flight/not responded to at any same given moment of time, as the refresh delay becomes longer and longer.

As a example:

Even with the maximum of 80 ("actual") concurrent Short-Term connections being the maximum before any new Short-Term connection requests are refused/denied. If your refresh rate had a 5 second delay between images for each viewer being refreshed.

It's fair to say that half or less of those connections would have a Short-Term request actually in progress at the same moments of time.

Allowing you to most likely be able to support as many or more then 125 individual viewers during that 5 second window period. Without denying any of their requests.

You can benchmark this, using the methods shown above with your IP Camera setup to verify where about this maximum is currently for your IP Camera with your current setup. You can try different tweaks to make your IP Camera more efficient and responsive and increase that number as well. More here:

post15934.html#p15934

Note: For better emulation of this you will want to add/delete some small amount of Milliseconds for each individual HTML line that you add, so that they all don't fire image refreshes at the same exact moments in time to better emulate actual viewers starting to view the IP Camera at not exactly the same times.

The most important point I can make as a response to you here is that using a "Visitor" level IP Camera User Id ("In the clear") still cannot save you from anyone who wishes to use that Visitor User Id and Password exposed in the clear, with your DDNS and/or IP Address and Port for the IP Camera.

Because all one anywhere in the world would need to do at anytime is to logon using that "Visitor" User Id and password 5 times, using the Standard IP Camera Interface that comes with the IP Camera and you the IP Camera owner would NOT be able to logon to your own IP Camera unless:

a. They stopped.
b. You sent a CGI command to the IP Camera to Reboot your IP Camera.
c. You went to the IP Cameras location and powered the IP Camera Down/UP.

Note: A creative person ("Using JavaScript as one example") could even create enough Short-Term concurrent connections as well to block others from being able to get Snapshots from your IP Camera. So basically, your IP Camera would be inaccessible by you the IP Camera owner as well as anyone else.

If someone did this right. You might NOT even be able to issue a CGI reboot command for your IP Camera because it requires a Short-Term connection to do that. Meaning now your only option would be to go to the IP Cameras location and power down/up the IP Camera.

Worse. If they continue to do this. You will need to again, each and every time, to go to your IP Cameras location and power down/up to the IP Camera.

This is because this is the only way to KILL the current connections to the IP Camera.

But....if they don't stop. Then as soon as your IP Camera is powered on and reboots. They will make new connections and do the same for as long as they please.

Whereas. When using the secure methods combined with this method. Nobody knows the DDNS or IP Address or User credentials of your IP Camera to play these games. As in Ever.

Point being that whatever IP Camera information you expose to the public can be abused.

This is why IMHO. It's never a good idea to expose any of your IP Camera information publicly. As stated here. The method shown here can be used securely, not only insecurely. In fact, all the working examples shown here are using this method, combined with the secure methods.

Don


Hey Don!

Thank you for responding.

It's been nice to fill in the gaps of knowledge I had missing as far as live-streams are concerned.

I did not necessarily mean flash players in particular, I referenced just players in general, any players you can think of and adjust to play live-stream videos live.

You made me smile regarding the js function. It is needed for the code to work. You have this function in your code as well. It's like an engine / motor for the code to work. If you say to your car that does not have a motor hey please, drive - nothing will work. The same is here. The <img src tag is only the "instruction" (saying to your car do drive), the work is done by the engine. The difference is that I simplified your code and separated the function (engine) from "instructions" (<img src tag). You have it on one long line altogether including your function, I have it working separately and my "engine" can be referenced in <head></head> like this <script language="JavaScript" src="engine.js" type="text/javascript"></script> without showing its code in page source and giving only "instructions" in a form of <img src on my main page.

My problem here was that I haven't tested it long enough yet and haven't checked a few other things.

Snapshot requests in progress in time at a time is where I have to look at and experiment. This is an excellent suggestion and explanation! Thank you! I also think this is exactly where I am stuck.

As for the visitor IP camera setup and your DoS (denial of service) attack mentioned as the most important point of your response it's clear and well-known. There are many different ways to protect yourself from these DoSes like IP tables rules for example (have used them for years) and so on but I'll go for hiding my ISP's IP and my visitor's login details via writing a few lines of php code. Your scripts gave me an idea how to do it in a very simple way.

Anyway, it's been very useful to read and to learn new things even though we side-tracked and went off the point.

Putting aside players issue does it actually mean that almost any IP cameras streaming live have limited concurrent connections? All the big guys like.. I don't know.. CNN for example who broadcast live online are also very limited in viewers that could watch them at the same time aren't they?
klaipedaville
 
Posts: 7
Joined: Mon Nov 25, 2013 2:25 pm

Re: A How To Embed Any Foscam IP Camera In Webpage Using 1 L

Postby TheUberOverLord » Mon Apr 14, 2014 3:33 pm

klaipedaville wrote:
TheUberOverLord wrote:You are very welcome.

1. Yes that's the issue. There is a difference on how most devices treat live video vs. recorded video.

This is because playing recorded video is more like a file transfer, you know where the video begins and ends and the other is streaming and has no beginning and potentially no end.

A good way to look at it is FTP. FTP allows you to transfer a file. But...the file must be complete not a file that has no beginning or end as of yet. In other words. You can FTP a video recording but you can't FTP a video stream because it has no beginning and has no current end.

While flash players may install without human intervention ("In some cases on some devices"). Not all devices support Flash and as time moves forward fewer devices will. So when I look at ("Any") browser capable device, I truly mean ("Any") browser capable device. From Computers/Laptops to Tablets and Phones to TVs. Which are running on any Operating System and using any browser.

More here about the ongoing demise of Flash and the current lack of any common standard across devices that can currently support live video:

http://blog.zencoder.com/2013/09/13/wha ... ml5-video/

2. Not sure why you need/require any js reload function to test your theory. Which I show using a working example below. Is not a correct one. Your testing methods are also giving your false results.

The img src = HTML line of code, is in fact doing the reload based on the value of 1000 Milliseconds ("1 Second") in the example code.

Therefore, you simply need to copy the img src = line for as many concurrent connections you wish to test for the same IP Camera.

Here is a example of using 12 Short-Term connections at the same time, with the same IP Camera, using a 1 second refresh rate. As you can see, it works fine.

I could have made it more then 12, But it gets the point across that the ("actual maximum") Short-Term concurrent conection limit is really 80. But that's 80 requests in progress/in flight/not responded to at any given moment in time.

http://107.170.59.150/short.htm

You can use free tools like Fiddler2, to in fact verify that the Short-Term Snapshot requests are not being rejected/denied and that in fact these Short-Term requests are automatically and immediately closed after the browser has received the Snapshot as well:

All 12 Concurrent Snapshot Requests Processed No Errors
Image

Connection Is Closed After Browser Receives Snapshot
Image

Please note that the total turn-around and processing time for the request above, was less then 1/2 a second which included adding the Date & Time and other text to the image after the image was received from the IP Camera. Without doing that extra work, it would have been much faster.

I say 100 is the virtual maximum Short-Term connection limit at 1 second refresh interval rates and the virtual Short-Term connection maximum limit becomes greater, with longer refresh delays.

This is because fewer Snapshot requests are in progress/in flight/not responded to at any same given moment of time, as the refresh delay becomes longer and longer.

As a example:

Even with the maximum of 80 ("actual") concurrent Short-Term connections being the maximum before any new Short-Term connection requests are refused/denied. If your refresh rate had a 5 second delay between images for each viewer being refreshed.

It's fair to say that half or less of those connections would have a Short-Term request actually in progress at the same moments of time.

Allowing you to most likely be able to support as many or more then 125 individual viewers during that 5 second window period. Without denying any of their requests.

You can benchmark this, using the methods shown above with your IP Camera setup to verify where about this maximum is currently for your IP Camera with your current setup. You can try different tweaks to make your IP Camera more efficient and responsive and increase that number as well. More here:

post15934.html#p15934

Note: For better emulation of this you will want to add/delete some small amount of Milliseconds for each individual HTML line that you add, so that they all don't fire image refreshes at the same exact moments in time to better emulate actual viewers starting to view the IP Camera at not exactly the same times.

The most important point I can make as a response to you here is that using a "Visitor" level IP Camera User Id ("In the clear") still cannot save you from anyone who wishes to use that Visitor User Id and Password exposed in the clear, with your DDNS and/or IP Address and Port for the IP Camera.

Because all one anywhere in the world would need to do at anytime is to logon using that "Visitor" User Id and password 5 times, using the Standard IP Camera Interface that comes with the IP Camera and you the IP Camera owner would NOT be able to logon to your own IP Camera unless:

a. They stopped.
b. You sent a CGI command to the IP Camera to Reboot your IP Camera.
c. You went to the IP Cameras location and powered the IP Camera Down/UP.

Note: A creative person ("Using JavaScript as one example") could even create enough Short-Term concurrent connections as well to block others from being able to get Snapshots from your IP Camera. So basically, your IP Camera would be inaccessible by you the IP Camera owner as well as anyone else.

If someone did this right. You might NOT even be able to issue a CGI reboot command for your IP Camera because it requires a Short-Term connection to do that. Meaning now your only option would be to go to the IP Cameras location and power down/up the IP Camera.

Worse. If they continue to do this. You will need to again, each and every time, to go to your IP Cameras location and power down/up to the IP Camera.

This is because this is the only way to KILL the current connections to the IP Camera.

But....if they don't stop. Then as soon as your IP Camera is powered on and reboots. They will make new connections and do the same for as long as they please.

Whereas. When using the secure methods combined with this method. Nobody knows the DDNS or IP Address or User credentials of your IP Camera to play these games. As in Ever.

Point being that whatever IP Camera information you expose to the public can be abused.

This is why IMHO. It's never a good idea to expose any of your IP Camera information publicly. As stated here. The method shown here can be used securely, not only insecurely. In fact, all the working examples shown here are using this method, combined with the secure methods.

Don


Hey Don!

Thank you for responding.

It's been nice to fill in the gaps of knowledge I had missing as far as live-streams are concerned.

I did not necessarily mean flash players in particular, I referenced just players in general, any players you can think of and adjust to play live-stream videos live.

You made me smile regarding the js function. It is needed for the code to work. You have this function in your code as well. It's like an engine / motor for the code to work. If you say to your car that does not have a motor hey please, drive - nothing will work. The same is here. The <img src tag is only the "instruction" (saying to your car do drive), the work is done by the engine. The difference is that I simplified your code and separated the function (engine) from "instructions" (<img src tag). You have it on one long line altogether including your function, I have it working separately and my "engine" can be referenced in <head></head> like this <script language="JavaScript" src="engine.js" type="text/javascript"></script> without showing its code in page source and giving only "instructions" in a form of <img src on my main page.

My problem here was that I haven't tested it long enough yet and haven't checked a few other things.

Snapshot requests in progress in time at a time is where I have to look at and experiment. This is an excellent suggestion and explanation! Thank you! I also think this is exactly where I am stuck.

As for the visitor IP camera setup and your DoS (denial of service) attack mentioned as the most important point of your response it's clear and well-known. There are many different ways to protect yourself from these DoSes like IP tables rules for example (have used them for years) and so on but I'll go for hiding my ISP's IP and my visitor's login details via writing a few lines of php code. Your scripts gave me an idea how to do it in a very simple way.

Anyway, it's been very useful to read and to learn new things even though we side-tracked and went off the point.

Putting aside players issue does it actually mean that almost any IP cameras streaming live have limited concurrent connections? All the big guys like.. I don't know.. CNN for example who broadcast live online are also very limited in viewers that could watch them at the same time aren't they?

You are very welcome.

Yes. I just meant that you could more quickly use my example as a baseline for testing for as short or as long as needed. With no false results of any kind.

I completely understood what you were trying to do with your JavaScript. I looked at it and can tell why it's failing. I also understood by your statements, that it failed to provide accurate results.

More here about my experience and background:

http://airforce.togetherweserved.com/sb ... erOverLord

IMHO. Your modified code actually complicates not simplifies the ability to easily stagger the refresh delay times per connection. Leaving one "common" delay time for all connections.

There are many valid and justifiable reasons to use my code example as is.

While my code example is visually on one line. It's still "Event Driven" and breaking my one line into multiple lines of JavaScript, to accomplish less then it's currently capable of doing, as is. Will only slow things down and make things less manageable and less flexible.

It can be important to be able to stagger the delay times per connection even a little, when trying to test and see how efficiently your local network and IP Camera(s) are setup.

This allows better emulation showing that not all visitors viewing the IP Camera(s) all will be requesting refreshed images all within the same 100 Milliseconds as an example.

This can become even more important if you are testing more then one IP Camera, using the same HTML page which will end up being in the same web page. To see how the combination of supporting more than one IP Camera in the same web page, at the same time, impacts your local network resources and IP Camera(s). Which can/could be different IP Camera models.

Ideally. If you were going to display more than one IP Camera in the same web page. You would be much better off staggering the refresh rates even slightly for each IP Camera to better balance the refresh requests.

There really is little you can personally do to protect a IP Cameras third-party DDNS from a DoS (denial of service) attack.

Also, creating 4+ concurrent Long-Term connections required to lock a IP Camera owner out of accessing their own IP Camera requires nothing like the sophistication and planning of a true DoS attack. An eight year old could do it. Without anything minus a browser to pull it off.

My statement was more meant for the average IP Camera owner who allows direct IP Camera access via their IP Cameras DDNS or their ISP IP Address in many cases.

Thanks for the kind words as well. I am just trying to be honest and provide details with my responses here.

Personally, I know of no IP Camera that does not have a finite limit for both Short and Long term connections.

Sadly, while there are some free live video server services most of them start charging once you require or exceed x concurrent connections and/or bandwidth per month.

So, this can be done again, without supporting all Internet browser capable devices. It also does not address the ISP IP bandwidth limitations that might be reached which you are lucky enough to not have.

It's important to note that while many Internet browser capable devices have some kind of ("Recorded") video player that can be or is installed. Few have video players that support ("Live") streaming video installed and/or quickly available that support all possible IP Camera live video streaming protocols and formats.

Many media sources use real-time video transcoding to provide many different video formats at the same time to get around that limitation of incompatible live video formats. But that takes some serious horsepower to do that for the total amount of possible live video formats required 24/7/365 to support virtually all known Internet browser capable device formats.

They also have many different device specific video player apps that require manually downloading and installing on some Internet browser capable devices.

News media sources either have their own live video server farms or pay some video server service to support their live video broadcasting needs. In many cases they use a combination of both to support as many Internet browser capable devices as possible. Even then currently no video streaming news service or video streaming service supports all Internet browser capable devices.

CNN Mobile:

http://www.cnn.com/help/mobile.html

Fox News Mobile:

http://www.foxnews.com/mobile/

So. The goals of these methods here, including the secure methods.

Is and are to support any and all Internet browser capable devices of any kind, automatically without any additional software required to be downloaded or installed and without any of those kinds of device limitations or capital investments required. In fact no capital investment of any kind.

For IP Camera owners and Imaging device owners. Using any IP Cameras or Imaging devices that support pulling Snapshots via HTTP or HTTPS.

Once IP Camera owners wish to support greater than 4+ FPS ("Frames Per Second") for 100+ concurrent viewers of their IP Cameras from any Internet browser capable devices. It's time for them to pull their hard earned money out. To do it right and correctly and it won't be cheap or free as these methods are.

Don
TheUberOverLord
 
Posts: 13105
Joined: Fri Jun 22, 2012 11:52 pm

Re: A How To Embed Any Foscam IP Camera In Webpage Using 1 L

Postby klaipedaville » Tue Apr 15, 2014 2:30 am

TheUberOverLord wrote:
You are very welcome.

Yes. I just meant that you could more quickly use my example as a baseline for testing for as short or as long as needed. With no false results of any kind.

I completely understood what you were trying to do with your JavaScript. I looked at it and can tell why it's failing. I also understood by your statements, that it failed to provide accurate results.

More here about my experience and background:

http://airforce.togetherweserved.com/sb ... erOverLord

IMHO. Your modified code actually complicates not simplifies the ability to easily stagger the refresh delay times per connection. Leaving one "common" delay time for all connections.

There are many valid and justifiable reasons to use my code example as is.

While my code example is visually on one line. It's still "Event Driven" and breaking my one line into multiple lines of JavaScript, to accomplish less then it's currently capable of doing, as is. Will only slow things down and make things less manageable and less flexible.

It can be important to be able to stagger the delay times per connection even a little, when trying to test and see how efficiently your local network and IP Camera(s) are setup.

This allows better emulation showing that not all visitors viewing the IP Camera(s) all will be requesting refreshed images all within the same 100 Milliseconds as an example.

This can become even more important if you are testing more then one IP Camera, using the same HTML page which will end up being in the same web page. To see how the combination of supporting more than one IP Camera in the same web page, at the same time, impacts your local network resources and IP Camera(s). Which can/could be different IP Camera models.

Ideally. If you were going to display more than one IP Camera in the same web page. You would be much better off staggering the refresh rates even slightly for each IP Camera to better balance the refresh requests.

There really is little you can personally do to protect a IP Cameras third-party DDNS from a DoS (denial of service) attack.

Also, creating 4+ concurrent Long-Term connections required to lock a IP Camera owner out of accessing their own IP Camera requires nothing like the sophistication and planning of a true DoS attack. An eight year old could do it. Without anything minus a browser to pull it off.

My statement was more meant for the average IP Camera owner who allows direct IP Camera access via their IP Cameras DDNS or their ISP IP Address in many cases.

Thanks for the kind words as well. I am just trying to be honest and provide details with my responses here.

Personally, I know of no IP Camera that does not have a finite limit for both Short and Long term connections.

Sadly, while there are some free live video server services most of them start charging once you require or exceed x concurrent connections and/or bandwidth per month.

So, this can be done again, without supporting all Internet browser capable devices. It also does not address the ISP IP bandwidth limitations that might be reached which you are lucky enough to not have.

It's important to note that while many Internet browser capable devices have some kind of ("Recorded") video player that can be or is installed. Few have video players that support ("Live") streaming video installed and/or quickly available that support all possible IP Camera live video streaming protocols and formats.

Many media sources use real-time video transcoding to provide many different video formats at the same time to get around that limitation of incompatible live video formats. But that takes some serious horsepower to do that for the total amount of possible live video formats required 24/7/365 to support virtually all known Internet browser capable device formats.

They also have many different device specific video player apps that require manually downloading and installing on some Internet browser capable devices.

News media sources either have their own live video server farms or pay some video server service to support their live video broadcasting needs. In many cases they use a combination of both to support as many Internet browser capable devices as possible. Even then currently no video streaming news service or video streaming service supports all Internet browser capable devices.

CNN Mobile:

http://www.cnn.com/help/mobile.html

Fox News Mobile:

http://www.foxnews.com/mobile/

So. The goals of these methods here, including the secure methods.

Is and are to support any and all Internet browser capable devices of any kind, automatically without any additional software required to be downloaded or installed and without any of those kinds of device limitations or capital investments required. In fact no capital investment of any kind.

For IP Camera owners and Imaging device owners. Using any IP Cameras or Imaging devices that support pulling Snapshots via HTTP or HTTPS.

Once IP Camera owners wish to support greater than 4+ FPS ("Frames Per Second") for 100+ concurrent viewers of their IP Cameras from any Internet browser capable devices. It's time for them to pull their hard earned money out. To do it right and correctly and it won't be cheap or free as these methods are.

Don


Hey Don,

Thank you for another response and your comments.

Well, you misunderstood or misread it a little. My code is working fine as well as yours. I have said it before. My code does not fail and gives me many short-term connections without any problems. Your code does the same. The only difference is in between refresh delay times per connection, you are right here on this one but this part is easily fixable and adjustable. I web-develop for a living so I am perfectly fine to write my own code (js, php, html, mysql, etc.). What I was trying to understand were the specifics of foscams to better develop or at least try to / attempt to set it the way I want.

There is also nothing wrong with testing it with your code as it is and take it for a baseline. I tried both to compare and you told me the results. I am not a video expert as you are so your advises help me see where it might be having trouble and I do thank you for that.

I do not use DDNS. I use static DNS of my ISP at the moment.

It looks like I may have to read some more on video server farms and video server services as I haven't deal with IP cameras before so it's quite new to me.

Anyway, thank you for responding once again. It's been quite useful to read and 'touch-test' it for real.
klaipedaville
 
Posts: 7
Joined: Mon Nov 25, 2013 2:25 pm

Next

Return to General Discussion

Who is online

Users browsing this forum: Yahoo [Bot] and 2 guests