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

[TheUberOverLord 0]

Many people have asked for ways to embed their 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.

 

WARNING - The following methods are NOT secure methods. Meaning that they expose the DDNS and/or IP Address location and Port of your IP Camera and a User Id and Password for your IP Camera. The same methods can be done securely as well. In fact the working example shown here is using the secure methods.

 

**Please visit here for those methods

 

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

 

Here is the one line needed in the webpage:

 

<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 IP Cameras:

 

MJPEG Based Foscam IP Camera:

 

<img src="http://DDNSorISPIPAddress:PortForCamera/snapshot.cgi?&user=UserId&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:

 

<img src="http://DDNSorISPIPAddress:PortForCamera/CGIProxy.fcgi?cmd=snapPicture2&usr=UserId&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 UserId and YourPassword with valid 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.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 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 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 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 IP Camera:

 

http://107.170.59.150/V31/EmbedIPCameraInWebPageOneLine.htm

 

The above methods are NOT secure methods. Meaning that they expose the DDNS and/or IP Address location and Port of your IP Camera and a User Id and Password for your IP Camera. The same methods can be done securely as well. In fact the working example shown here is using the secure methods.

 

Please see this for those methods:

 

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

 

[MOD: edited to highlight security vulnerability]

 

Don

Edited March 27, 2014 by Guest

[drocer 0]

"Here is how to point a loaded gun at your head. BTW don't do that."

 

Reported. I hope you get banned.

[TheUberOverLord 0]

"Here is how to point a loaded gun at your head. BTW don't do that."

 

Reported. I hope you get banned.

Reported for what? Showing an easy method to refresh IP Camera images and other images easily in the "IP/Megapixel Cameras and Software Solutions" forum area.

 

Nice to meet you as well. Hope you have a better day, week, month, year and life.

 

Don

Edited March 26, 2014 by Guest

[hardwired 0]

"Here is how to point a loaded gun at your head. BTW don't do that."

 

Reported. I hope you get banned.

He's showing ways to embed images into webpages, not exposing vulnerabilities. He's also taken the time to explain ways to increase security of those video feeds by obfuscating the IP and login information.

 

He isn't explaining inurl: or other vulnerabilities, quite the opposite.

 

However, a thorough dissection of vulnerabilities is usually the only way they get fixed, so that's not always a bad thing, security through obscurity is always a bad idea.

[TheUberOverLord 0]

"Here is how to point a loaded gun at your head. BTW don't do that."

 

Reported. I hope you get banned.

He's showing ways to embed images into webpages, not exposing vulnerabilities. He's also taken the time to explain ways to increase security of those video feeds by obfuscating the IP and login information.

 

He isn't explaining inurl: or other vulnerabilities, quite the opposite.

 

However, a thorough dissection of vulnerabilities is usually the only way they get fixed, so that's not always a bad thing, security through obscurity is always a bad idea.

Thanks.

 

Yes. Actually. At the bottom of the post there is a link to totally secure methods that can be used as well with this method. Not simply obscured and/or obfuscating methods, but totally secure methods.

 

In fact the working example presented here is also using those totally secure methods.

 

You can use any tool you wish from things like Fiddler to Wireshark and others and you can see that the working example has nothing that can be found when/while using it as to where the DDNS/IP Address location or Port and or what User credentials were used for the working example to get the images from the originating IP Camera used in the working example.

 

Sadly. It's obvious that "drocer" did not understand and/or comprehend the example or its abilities to be used both securely and not securely using 1 line of HTML code per IP Camera, imaging device or image vs. many or multiple lines of code, which is normally the case.

 

Don

[drocer 0]

I did comprehend it. When is putting the user/pass in an public facing HTML file good? You are aware idiots/morons won't heed your tiny warning at the bottom. They will put this right on the internet. Yes, it's just an example of how to do it with no security but its absolutely irresponsible to even show that at all IMHO. IP cameras are borderline linux boxes and should be treated as such at all times. The only problem is these linux boxes have security exploits waiting to be found and you're telling people how broadcast ROOT to the world.

 

http://myusername:mypass@123.123.123.123/web/docs/badsecurity.jpg

 

Here's how to embedded an image from a protected storage. Oh btw, that's not secure.

[ak357 0]

"Here is how to point a loaded gun at your head. BTW don't do that."

 

Reported. I hope you get banned.

He's showing ways to embed images into webpages, not exposing vulnerabilities. He's also taken the time to explain ways to increase security of those video feeds by obfuscating the IP and login information.

 

He isn't explaining inurl: or other vulnerabilities, quite the opposite.

 

However, a thorough dissection of vulnerabilities is usually the only way they get fixed, so that's not always a bad thing, security through obscurity is always a bad idea.

+1 Hardwire

@TheUberOverLord

plz keep posting

[TheUberOverLord 0]

"Here is how to point a loaded gun at your head. BTW don't do that."

 

Reported. I hope you get banned.

I did comprehend it. When is putting the user/pass in an public facing HTML file good? You are aware idiots/morons won't heed your tiny warning at the bottom. They will put this right on the internet. Yes, it's just an example of how to do it with no security but its absolutely irresponsible to even show that at all IMHO. IP cameras are borderline linux boxes and should be treated as such at all times. The only problem is these linux boxes have security exploits waiting to be found and you're telling people how broadcast ROOT to the world.

 

http://myusername:mypass@123.123.123.123/web/docs/badsecurity.jpg

 

Here's how to embedded an image from a protected storage. Oh btw, that's not secure.

Since I can't FIX your attitude and/or altitude issue(s).

 

I can only suggest that you read the "About Me" link in my signature and also suggest that you re-read my initial post here where it shows both unsecure and secure methods ("Using the same Font and Font size").

 

How camera owners choose to implement the method is their business not yours or mine. They have access to both methods and can do as they please.

 

Point being, that they now have the methods. They may not care about using a camera insecurely and I have no need or desire to try and force them to do anything they don't wish to do.

 

A fair warning was given in the post and the working example IS using the secure method and was stated to be doing so. A link was also provided to help implement the use of secure methods as well.

 

If you wish to refer to those things clearly stated in the original post as a "tiny warning" that's also your choice. But, it's not a true and accurate assessment or statement of what content was and is included in the original post.

 

I trust that people here can read and that the vast and overwhelming majority of readers here are not as you say "idiots/morons" and since the Font used in the entire post is the same Font and size. Nothing in the original post is smaller than anything else.

 

Secondly. It would appear, based on your clear and accusatory statements made here. That your basic current comprehension/understanding of how the communications normally flow and takes place with the vast majority of IP Cameras which use a Browser to communicate with the IP Camera owner and that IP camera when using HTTP as the transport protocol and video stream protocols is flawed.

 

Generally for most IP Camera brands and models. Even if the IP Camera in question is using some form of basic authorization when the IP Camera owners Browser is accessing the IP Camera. The same information ("Exposure of data") which you seem to be so very concerned about here. Is in fact ("Always") taking place ("Again with the vast majority of IP Cameras") with the normal and standard IP Camera/Browser communications that takes place and can just as easily be decrypted/decoded if need be. When the Browser and the IP Camera in question are using HTTP.

 

So. It does not require that a IP Camera owner create special ("non-secure") requests to the IP Camera, like as one example of asking the IP Camera for a snapshot to create this data exposure or to expose this same data. This data exposure that you seem so concerned about, is generally ("Always") there when communicating with most IP Camera brands and models using a Browser and HTTP.

 

This is well known fact and not fiction and can be easily verified using free tools such as Fiddler, Wireshark and many other tools. That allow packet level inspection of the communications protocol layers from the IP Camera and a Browser when using HTTP as the transport mechanism between the IP Camera and the Browser in question.

 

This is why many newer IP Camera models have a HTTPS option. Which still does nothing to remove the potential of a man-in-the-middle exploit when using a public or semi-private Internet connection.

 

Whereas, my secure methods use a Web Server as a Proxy between the IP Camera and any Browser to protect the IP Camera owner from this data exposure, these flaws and/or potential exploits. Even when the IP Camera owner uses a public or semi-private Internet connection. Those methods are totally secure as to being able to protect others from gaining access to any DDNS/IP Address, Port or User Credentials for a IP Camera when a Browser is using those methods with any IP Camera.

 

Had you truly understood this to be fact and not fiction. Again as being generally the usual case for normal communications for most IP Cameras and a Browser using HTTP. Then your focus would not be or have been so narrowly focused on the use of this method also having the ability to also be used in a non-secure way. Since normal communications for most IP Cameras using HTTP is exposing the same data ("Even if someone needed to use a online tool to decrypt any basic authorization which is/was being used to get the IP Camera User and Password being used") and information.

 

IMHO. If you take the time to educate yourself on how the normal communications flow takes place with most of these IP Cameras and a Browser when they are used by a IP Camera owner using HTTP. You would soon learn quickly, that generally this data exposure, which seems to be so "shocking" to you. Has been for many years and is today, constantly present and taking place with the vast majority of IP Camera brands and models which use HTTP as their standard camera interfaces. During typical and normal communications with the IP Camera when using a Browser and HTTP and video streaming protocols.

 

Who knows?

 

If you take the time to do the above. You might ask fewer people publicly to kill themselves, not have as much a need to report those you've asked publicly to kill themselves as often, worry less about idiots/morons and see tiny warnings as the sizes they really are

 

Sounds like a win-win to me. You gain more knowledge, Moderators need less medication and your eyesight gets better. All in the same period of time!

 

Don

Edited March 27, 2014 by Guest

[TheUberOverLord 0]

"Here is how to point a loaded gun at your head. BTW don't do that."

 

Reported. I hope you get banned.

He's showing ways to embed images into webpages, not exposing vulnerabilities. He's also taken the time to explain ways to increase security of those video feeds by obfuscating the IP and login information.

 

He isn't explaining inurl: or other vulnerabilities, quite the opposite.

 

However, a thorough dissection of vulnerabilities is usually the only way they get fixed, so that's not always a bad thing, security through obscurity is always a bad idea.

+1 Hardwire

@TheUberOverLord

plz keep posting

Thanks so much.

 

Don

[hardwired 0]

Yes, it's just an example of how to do it with no security but its absolutely irresponsible to even show that at all IMHO.

This same type of example is shown on most IP camera manufacturer's sites, without any warnings whatsoever, at least he mentions the vulnerabilities of doing it that way!

IP cameras are borderline linux boxes and should be treated as such at all times. The only problem is these linux boxes have security exploits waiting to be found and you're telling people how broadcast ROOT to the world.

Wait until IPV6 gets traction, and all of those devices are exposed to the internet without even NAT as a basic safety net, that's going to be fun... Internet of Things botnet, here we come!

[ak357 0]

Wait until IPV6 gets traction, and all of those devices are exposed to the internet without even NAT as a basic safety net, that's going to be fun... Internet of Things botnet, here we come!

Are we going to see u in LV next week ?

[hardwired 0]

Wait until IPV6 gets traction, and all of those devices are exposed to the internet without even NAT as a basic safety net, that's going to be fun... Internet of Things botnet, here we come!

Are we going to see u in LV next week ?

Thursday and Friday, see you there!

[ak357 0]

Thursday and Friday, see you there!

Thursday 6 pm usual place

[TheUberOverLord 0]

Yes, it's just an example of how to do it with no security but its absolutely irresponsible to even show that at all IMHO.

This same type of example is shown on most IP camera manufacturer's sites, without any warnings whatsoever, at least he mentions the vulnerabilities of doing it that way!

IP cameras are borderline linux boxes and should be treated as such at all times. The only problem is these linux boxes have security exploits waiting to be found and you're telling people how broadcast ROOT to the world.

Wait until IPV6 gets traction, and all of those devices are exposed to the internet without even NAT as a basic safety net, that's going to be fun... Internet of Things botnet, here we come!

Thanks.

 

Honestly. I can't locate one true statement drocer has made in this entire thread. No joke.

 

drocer won't and does not get that.

 

Just the statement alone, that I should be "Banned" when drocer reported me. Even when I had included a link to secure methods ("In the same Font and Font size as ALL the other content in the same post") while I also stated in the same post that the example method shown was not secure and also stated that the working example shown in the post, was using those secure methods. Shows that.

 

Much like drocer's misleading and false statement of my warning being a tiny one. drocer also makes another false statement and claim that the post was asking camera owners to "broadcast ROOT to the world" when the original post contents also suggests using a IP Cameras Visitor User Level Id.

 

drocer also seems to not understand that ROOT is a Linux term and that generally there is not ROOT access from CGI commands to IP Cameras.

 

While the serial interfaces, FTP and Telnet interfaces to IP Cameras in many cases can and do support ROOT Access. CGI ROOT access is generally not supported. It would seem that drocer seems to think that a Admin Level ("Visitor Level was suggested in the post") IP Camera User Id for IP Camera logon purposes = Root. Which it does not.

 

drocer then continues on to make more false statements and claims "IP cameras are borderline linux boxes" When there is nothing boarderline about it. IP Cameras are Linux boxes:

 

http://www.openipcam.com/forum/index.php/topic,473.0.html

 

http://foscam.us/forum/fi9821w-constantly-rebooting-t4912-20.html#p30784

 

I know this because I help other Foscam IP Camera owners recover any and all of their Foscam IP Camera models, as needed, using the serial interfaces to their Foscam IP Camera model. Using ROOT Linux access methods. I also have done the same with other camera models for many years.

 

drocer also needs to learn that anything connected to the Internet is an exploit waiting to happen. NOT just IP Cameras. There are ways and methods to keep your ears close to the ground to avoid most if not all of them. Which I also have used and share with others:

 

http://www.openipcam.com/forum/index.php/topic,534.0.html

 

According to drocer. The manufacturers of IP Cameras also are as drocer says "absolutely irresponsible to even show that at all" or that they must have found methods not yet known to mankind to keep idiots/morons ("Who drocer has a personal quest on protecting access to this information, from those KINDS of people") from reading the information contained in their publicly posted links.

 

Hopefully in the near future, drocer will start some studying on how even the IP Camera manufacturers as you say, without any warnings whatsoever, show the use of these same methods. Some examples of many ("Several hundred actually"):

 

http://foscam.us/forum/cgi-sdk-for-hd-camera-t6045.html#p28979

 

http://foscam.us/forum/cgi-api-sdk-for-mjpeg-h-264-camera-t2986.html#p13630

 

http://developer.samsungtechwin.com/sdk/sdk.asp

 

http://www.hikvision.com/en/us/download_more.asp?id=957

 

Hopefully, at the same time, drocer will try to lean how the normal communication flows from generally all these IP Cameras when they are using a HTTP interface to a Browser. As I suggested in a prior post here.

 

Most likely. That's wishful thinking. Sigh!

 

I guess in the meantime IP Camera Manufacturers, IP Camera owners, Forum members and Forum visitors will all need to accept and live with and continue to remain in drocer's idiots/morons category and classification groups

 

At the very least we can all be thankful that IP Camera manufactures seem to not have the same "Paranioa" that drocer has about the wrong ("Types of") people being exposed to actually seeing these same methods, without the ("Extra") drocer warnings requirements and causing harm to themselves and others while doing so.

 

Don

Edited March 27, 2014 by Guest

[Securame 0]

The thread does also seem useful to me.

 

If somene would decide to do this using the admin account, well, no comments... I guess that anyone who is able to embed an image on a web page should know better than that.

[TheUberOverLord 0]

The thread does also seem useful to me.

 

If somene would decide to do this using the admin account, well, no comments... I guess that anyone who is able to embed an image on a web page should know better than that.

Thanks.

 

I agree. I think it has even been shown here that IP Camera manufactures think the same and don't share the same level of paranoia that drocer has expressed and shown here.

 

I think, when possible however people should think about using the secure method. Especially more so if you don't want people to have access to your video streams. Which they still could get to even when using a Visitor User Level Id for the method when it's being used insecurely. As well as if the camera is going to contain in the configuration Email and/or FTP User Id and Password information that could be exploited if the firmware updates were not being maintained for the IP Camera in question.

 

I personally trust that as you say any camera owner who has a website and is going to use this method insecurely in a public HTML page. Hands-Down, knows the risk as they are typing their IP Cameras DDNS/IP Address, Port and User credentials. To suggest otherwise, is nothing but pure conjecture. IMHO.

 

For private use. By those that don't have a website or don't wish to keep a copy of this method on their websites. Some may wish to simply store the HTML page on any Internet browser capable device they may have or store a copy of it as an Email attachment that can be accessed from anywhere and used from any Internet browser capable device at anytime. This also justifies the use of using this method insecurely on secure internet connections for private use. Since the same data would be exposed if you were to access a video stream or use the normal IP Camera Interface from a browser.

 

It can also come in handy in an emergency when you at the moment don't have access to your normal devices yet someone you trust has Internet access on a device that has no app for your camera. Then you can at least access your Email use the stored copy of this method from that device to check on if your camera is operational even from their device.

 

It should be noted that this same method can in fact be used using HTTPS from a website. If your camera also supports HTTPS. With NO modifications or changes. So, if you have a website and a SSL certificate you can use the insecure method securely on a secure Internet connection. I would worry about doing the same using a semi-private or public Internet connection because of potential man-in-the-middle exploits.

 

All the examples used here are SMALL for demonstration purposes. They can be any size.

 

Here is an example of HTTPS access using the secure method combined with this method. Please note the web server hosting this example is using a self-signed SSL certificate so you will get a warning. The camera being used in this example is a MJPEG based IP Camera which does not natively support HTTPS. But because the secure method is also being used as a proxy to the camera. HTTPS access can still take place:

 

https://107.170.59.150/V31/EmbedIPCameraInWebPageOneLine.htm

 

Note: You can review the HTML source for the above if needed. Even if a man-in-the-middle attack were to take place using the above link No exposure of any IP Camera data could ever take place. Since the secure method is acting as a proxy to the IP Camera in this example.

 

The same concepts can be used insecurely or securely using the method shown here in this thread/topic as this example shows using any combination of IP Camera Brands and Models and Types. The below shows both MJPEG and H.264 based IP Camera models at the same time using this method combined with the secure method:

 

https://107.170.59.150/foscam/FoscamUS.htm

 

Four of the Nine IP Cameras shown above don't support HTTPS access methods natively but because the secure method is being combined with this method those cameras can in fact be accessible via HTTPS with the secure method acting as a HTTPS/HTTP bridge proxy to those IP Cameras which normally would not be accessible via HTTPS.

 

Note: Again, please feel free to review the HTML source code for the above as needed.

 

Don

[drocer 0]

The thread does also seem useful to me.

 

If somene would decide to do this using the admin account, well, no comments... I guess that anyone who is able to embed an image on a web page should know better than that.

 

Not doubting usefulness, just the presentation that certain terrible security practices can be okay. There's no way anyone was suggesting using admin...

 

 

H.264 Based Foscam IP Camera:

 

Code:

 

And with that, I'm logging out and leaving this site, not because of this thread but how this site is run. It just wears you down over time as this is less a forum and more of just a sales platform for installers/integrators.

[TheUberOverLord 0]

Once again, drocer has taken things "Out Of Context" as has been done in EVERY post here. IMHO.

 

The original first post here in this Topic has always included ("Text") which of course when drocer has posted here, is never included with drocer's selected "Snippets" of the original first post content of this Topic, stating the following:

 

1. It's suggested to use a Visitor User Level Id for the IP Camera(s) when using the method.

2. To NEVER <- Which is and has always been In Capital letters "use an Admin User Level Id with the method" when it's being used insecurely.

 

The thread does also seem useful to me.

If somene would decide to do this using the admin account, well, no comments... I guess that anyone who is able to embed an image on a web page should know better than that.

Not doubting usefulness, just the presentation that certain terrible security practices can be okay. There's no way anyone was suggesting using admin...

 

H.264 Based Foscam IP Camera:

 

Code:

And with that, I'm logging out and leaving this site, not because of this thread but how this site is run. It just wears you down over time as this is less a forum and more of just a sales platform for installers/integrators.

It's common ("Nomenclature") even by manufactures ("See example below") who publish SDK manuals for their IP Cameras to use as an ("Example") the User Id of admin as a reference:

 

From Foscam H.264 Based IP Camera CGI SDK Manufacturers Manual

From: http://foscam.us/forum/cgi-sdk-for-hd-camera-t6045.html#p28979

 

Note: Yet the IP Cameras User Id privilege level required to execute the above is a visitor level, not an admin level. This is the EXACT command I reference here. Yet when I do it the same way as the manufacturer does above. drocer seems to require a change of underwear.

 

drocer's initial post in this thread/topic ("In its entirety") was:

 

"Here is how to point a loaded gun at your head. BTW don't do that."

 

Reported. I hope you get banned.

I did not understand it when it was posted nor do I understand it today.

 

Trying to pin down drocer's concerns in this thread has been for me at least like playing "Whac-A-Mole". drocer's posts here have swung wildly from one thing to another and the one posted below here shows that drocer feels/thinks that one should never use CGI commands for a IP camera as in ever in a public HTML file. Which also has nothing to do with the fact that this method can also be used with HTTPS methods if the IP Camera supports HTTPS access and privately as well and used and hosted from any Internet browser capable device without the need for the HTML to be hosted on any website period. Which shows and continues to show me that dorcer has not been able to grasp, all the ways this method can be used.

 

When is putting the user/pass in an public facing HTML file good? You are aware idiots/morons won't heed your tiny warning at the bottom.

That said. In case drocer's idiots/morons ("As he calls them") that drocer has been so protective of ("In his posts in this thread/topic") really exist and ("Stay") after drocer has left. I replaced "admin" where it was referenced by drocer's ("Snippet") of the original post content and replaced it with "UserId". I also made the word "NEVER" bold and underlined as well.

 

Hopefully now. drocer's idiots/morons ("As he calls them") will no longer be able to hurt themselves or others when using this method if they decide to stay after drocer has left. As the original first post of this topic also has stated, since its creation. This method can be combined with secure methods as well. The original post, since its creation, has always had a link to those secure methods as well.

 

Don

[Gowfster 0]

Uber,

I really liked your 1/sec approach to screen captures vs the live feed (although I may want to do the live feed at some point also).

I'm pretty new to both CCTV and to HTML coding, so apologies that i'm not getting it to work.

 

I have tried a number of variations to no avail. I presume that there are nuances for each camera to get to the right page/ frame capture based on the differences in your two Foscam examples

I have a Lorex IP camera, which appears to be a Hikvision really.

 

I just seem to get a blank window and the broken photo icon in the center of it

 

I'd really appreciate any pointers on this.

[TheUberOverLord 0]

Uber,

I really liked your 1/sec approach to screen captures vs the live feed (although I may want to do the live feed at some point also).

I'm pretty new to both CCTV and to HTML coding, so apologies that i'm not getting it to work.

 

I have tried a number of variations to no avail. I presume that there are nuances for each camera to get to the right page/ frame capture based on the differences in your two Foscam examples

I have a Lorex IP camera, which appears to be a Hikvision really.

 

I just seem to get a blank window and the broken photo icon in the center of it

 

I'd really appreciate any pointers on this.

Thanks.

 

What URL ("If any") works currently for your camera when using it from a browser window directly to your camera for a snapshot?

 

You can replace any private data with made up data.

 

Don

[Gowfster 0]

To access my cameras directly, I use their IP address, which leads to a login page that asks for User Name and Password. That page is:

http://192.168.1.124/doc/page/login.asp

 

after typing in my info, it goes to page

http://192.168.1.124/doc/page/main.asp, and on this page it contains the camera video live in a window, with menu options around the periphery of the window. I know the first time I ran it, I recall Win7 asking to approve using a codec or something to see the live video.

 

When I try to go direct to the second page while not logged in, it redirects to the login page.

 

The camera is MCNB2153

 

Does this help?

[TheUberOverLord 0]

To access my cameras directly, I use their IP address, which leads to a login page that asks for User Name and Password. That page is:

http://192.168.1.124/doc/page/login.asp

 

after typing in my info, it goes to page

http://192.168.1.124/doc/page/main.asp, and on this page it contains the camera video live in a window, with menu options around the periphery of the window. I know the first time I ran it, I recall Win7 asking to approve using a codec or something to see the live video.

 

When I try to go direct to the second page while not logged in, it redirects to the login page.

 

The camera is MCNB2153

 

Does this help?

I personally don't know what URL can be used directly from a browser window to pull a snapshot from this camera model. Maybe someone else here knows?

 

The end-goal is to not need to go to the logon page first.

 

Don

[akelley 0]

 

And with that, I'm logging out and leaving this site, not because of this thread but how this site is run. It just wears you down over time as this is less a forum and more of just a sales platform for installers/integrators.

 

Bye!

[Fork God 0]

Hi i don't want people accessing my admin info and i am a bit confused with the link on how to protect and hide the admin info, can you help me pls?