Refreshing Image URL quit working for IP Video Cameras

I think that the firmware change is actually related. Indigo doesn't support the MPEG format. It sounds like if you do a save-as you do get a JPG, which Indigo does support, but I believe that is the browser taking a snapshot from the stream and saving it as a JPG. Hopefully the camera supports getting a JPG snapshot directly somehow, via a different URL. It used to before the firmware change.

To be clear, MJPEG was the format on older versions of the FW, and is not the same thing as MPEG. The fact that I am getting a 403 error, leads me to believe it is the authentication mechanism or resulting URL format required, and not the format of the image stream.

But to your point, something in the FW is not playing nicely any longer.

I appreciate all the help, and for now I will try to revert the FW using TFTP, or just wait for a newer firmware that hopefully addresses this issue.

Thanks,

Chris

[matt (support)]

Gotcha. I didn't notice the J in MPJEG. I am a bit surprised that Indigo works with that format, but it would definitely be more possible than MPEG.

Indigo doesn't do any type of parsing on the URL arguments. Those just get passed directly through to the camera's Web server.

Try using a URL that not only includes the base64 encoded URL argument, but also includes the username/password at the beginning:

Code: Select all

http://username:password@ip:port/Streaming/channels/1/preview?auth=xxxxxx

[jay (support)]

Just to clarify: it's MJPEG (not MPJEG) and it stands for Motion-JPEG. It's a video format where each frame is compressed using JPEG. I'm very surprised that Indigo ever actually worked with that since it's inherently a video format - just using JPEG as the compression. I wonder if the MJPEG format used by the older camera firmware delivered content differently (maybe an older MJPEG spec) and Indigo was able to interpret each frame or some such.

Just to clarify: it's MJPEG (not MPJEG) and it stands for Motion-JPEG. It's a video format where each frame is compressed using JPEG. I'm very surprised that Indigo ever actually worked with that since it's inherently a video format - just using JPEG as the compression. I wonder if the MJPEG format used by the older camera firmware delivered content differently (maybe an older MJPEG spec) and Indigo was able to interpret each frame or some such.

Yeah, that was a typo on my part.

This video camera company (HIKVision) has proven to me that they are great about frequent FW updates, but they are not always fully baked.

This is the first time I cannot downgrade the FW easily (without a complicated TFTP scenario).

At this point I will just have to see if a future FW update resolves the issue.

So not wanting to give up, I did some serious digging, and found out a few things:

When using my admin account vs the view account which worked before, and changing to channel 2 on the cameras feed, as well as using the old login format, I was able to get Indigo to work. So the format looked like this:

Code: Select all

http://adminusername:adminpassword@ip:port/Streaming/channels/2/picture

Long story short, I was able to get everything back to the way it was, with one simple change: elevated permissions for the view account. Now mind you, none of the permissions I have now added to this view account make any sense, and seem totally unchanged from the previous FW versions, but it does work.

Also interesting is that I can use the base64 authentication with the admin account to see channel 1 or 2, but it doesn't work right for the view account. I chalk it up to buggy FW.

Thanks for all the assistance, I am back in business.

For others, here is what worked for me (pretty much unchanged from what I have been using for over a year):

Code: Select all

http://username:password@ip:port/Streaming/channels/1/picture

with the view user account set as "Operator" and all possible permission boxes checked.

My cameras are HIKVision DS-2CD2132-I and DS-2CD2032-I with FW 5.2.0