Page 3 of 6

Re: ProHD No Video using HTTPS

Posted: Wed Jul 27, 2016 10:42 am
by shabuboy
This is what I got from support....

"You will have to go into the caemra settings of the camera and then lower the frame rate or the bitrate of the camera in order to get it showing. That error message is because the bandwidth of your internet is not fast enough."

Re: ProHD No Video using HTTPS

Posted: Wed Aug 10, 2016 3:19 pm
by Jarrah
I'm returning mine as defective due to this issue. Having received it a few days ago and subsequently encountered the same HTTPS live stream error on Safari, it most definitely isn't fit for purpose so sending it back.

Who seriously would want to remotely access their camera over an insecure connection where credentials could be sniffed out and then used to spy on you remotely... Thanks but no thanks Amcrest.

This was recommend to me by a colleague at work who already got two other people to buy this, but I'll be asking if they're aware of how easy it is to pick up their credentials by using port 80 as they do, and that opening up this port to the internet on their router is a very bad idea...

(I have 200MB broadband, with uploads being 50MB, so bandwidth is not the issue here)

Re: ProHD No Video using HTTPS

Posted: Wed Aug 10, 2016 3:26 pm
by Jarrah
newbie wrote: To others I know it is not the best but I do believe it is possible to setup a reverse proxy using NGINX, I have done this for other devices but not tried it for this one yet as an interim solution. I might re-purpose a raspberry Pi for this for till the fix is out.
I tried adding the camera to my Raspberry Pi reverse proxy set up as well, but the web page lost all it's formatting and just showed text in an unformatted way. Could be my proxy settings are wrong so would be interested to know if someone has it working?

Along with the HTTPS issue, it's a shame the field of view angle isn't greater than 90 degrees. I'm used to the 160 degree fish eye lenses you can buy for Raspberry Pi's that also come in NOIR flavour, so 80 degrees is really limited when using the non-movable outdoor bullet camera.

Re: ProHD No Video using HTTPS

Posted: Wed Sep 28, 2016 5:22 pm
by amcresthell
Can confirm this.

The following works fine:

1) http from within my network
2) https from within my network
3) http from outside my network via ddns

The following does not work:

4) https from outside my network via ddns

To Amcrest/Melvin: Can you please give us information on this and when it will be fixed. Thanks.

Re: ProHD No Video using HTTPS

Posted: Thu Sep 29, 2016 1:34 am
by josesmith
Don't forget to do the port forward for your RTSP url, the default port number is 554.

Re: ProHD No Video using HTTPS

Posted: Thu Nov 03, 2016 5:19 pm
by amcresthell
Bumping this again, is there any resolution on this issue? We really should be able to use HTTPS with DDNS from outside of our network. I really don't like sending my credentials in the clear every time I log in.

Since it sounds like Melvin is the only support guy here... Melvin, can you please provide info on this bug?

Thank you.

Re: ProHD No Video using HTTPS

Posted: Fri Nov 04, 2016 1:52 pm
by Melvin
Hello amcresthell ,

This bug has been reported to the R&D team. More feature upgrades and bug fixes are on the way with new firmware releases. We apologize for the inconvenience.

Re: ProHD No Video using HTTPS

Posted: Thu Nov 10, 2016 12:51 pm
by PsychoPhreak
Can confirm. I've been back and forth with R&D and software dev's about this issue since 9/13 through support e-mails, and this is what I received in a followup today:

Good Morning

There will be a firmware release for this. When it is release it will be show on our Amcrest website
Thank you & have a great day.
Kind Regards,
Jono Fletcher
Help Desk Specialist
Monday - Friday 9:30AM - 5:30PM CST

Re: ProHD No Video using HTTPS

Posted: Fri Dec 09, 2016 9:37 pm
by GRSmith
RE: "Resources are limited, Failed to play video stream"
This is what cured that problem for me...

First... you have to be able to logon to the web interface built into the camera... but most of you seem able to do that part just fine. In other words... if your camera IP is 192.168.44.23, then point your browser (Mozilla, Edge, IE11 or Chrome) at http://192.168.44.23.

Second... navigate to Setup/Network/Connection and change the "HTTP port" from its default (80) to something else. The very first thing I tried was 1026.

Third... you will now lose contact with the camera. To regain connection add the chosen port number to the URL above. In this example: http://192.168.44.23:1026

Prior to all this... and like many of you... I had already installed the ActiveX control under IE11 and the Web App under Chrome. I could not install anything under Edge since the redirect your given in Edge simply points you at the Chrome Web App. So... I am guess Edge will never work for this. Mozilla I am still up in the air over.

At any rate... both IE11 and the Chrome Web App will now display the video stream just fine (at least for me).

Re: ProHD No Video using HTTPS

Posted: Sun Dec 11, 2016 11:38 am
by GRSmith
One follow-up to my Dec 09, 2016 9:37 pm
Under Setup/Network/Connection, the line for "HTTP port" has no text to the right of its textbox (unlike some other textboxes on that page). However, if you open the context-sensitive "Help Center", that text does advise the following for your entry into "HTTP port":

This is the HyperText Transfer Protocol communication service port. The values range from 1025 to 65534.

There are also warnings at the bottom of that Help section advising as follows:

Please note:
1. Do not use port values such as 0-1024, 37780-37880, 1900, 3800, 5000, 5050, 9999, 37776, 39999 and 42323 since they are used as special ports for other common communication service protocols.
2. When setting the port value, it's not recommended to use another service's default port value to avoid a conflict causing your service to not work properly.


Just guessing but...this is maybe why Amcrest wants to change the firmware... to revise that interface adding a recommended port range for "HTTP Port", as they already do for "TCP Port" and "UDP Port".

The fact that it initially defaults to 80 makes sense to me, since that would be the normal assumption of anyone attempting to reach a web interface for configuration purposes.