Remote Viewing Bandwidth Limitations?

It will transcode it but what do you do with multiple clients want to watch? It will still need to send out multiple redundant copies, which will overload the link.

You might want to put the Ocularis X component upstream but then how do you connect to the video streams from the existing recorder and, even if you could, you don't have enough bandwidth to send those 8 streams across the link, without radically reducing quality / frame rate.

Here's something that may help... while the 'A' in ADSL means asynchronous, the normal understanding of the connection is usually off.

Think of an ADSL link as a link with a budget. You can either stream up or down at the rated speeds. For example, you have a DSL link capable of 7.62Mbps down and 768Kbps upstream. This means that at any given time, you can use 100% of the link for 7.62Mbps downstream, or 100% of the link for 768Kbps upstream. In the real world, you will always have packets flowing both ways, so you will need to enact Quality of Service (QoS) and bandwidth throttling to acheive the results you may want to see.

So, for example, I would take the same link, and throttle the downstream to 1Mbps. This is the first step to preventing too much incoming traffic from allowing the higher outgoing speed. By limiting the downstream on the link we're discussing to 1Mbps downstream, we leave the capability to simultaneously have a 667 Kbps upstream data flow. This works because of the budget I just mentioned- 1Mbps of the 7.62Mbps would be 13% of the total link capacity. That leaves 87% for the upstream link. 87% of 768Kbps is 667Kbps.

In order to get this to work, you will have to attack with a few options:

• Investigate other means of connectivity that fits your budget. 768kbps is not alot, and a T1 would be better since it's a SYNCHRONOUS link- 1.544Mbps in both directions, simultaneously. Can you get cable as well? Can you upgrade the DSL link to a faster upstream speed?
• Install a firewall / router with multicast (PIM-SPARSE) support, VPN, throttling, and QoS. Configure to make sure the clients are prioritized, that downlink traffic is VERY limited (say down to 256Kbps), VPN is setup with a low overhead encryption such as Blowfish, AES128, or... gasp... 3DES.
• Multicast! Reduce the bandwidth requirements across the board by enabling a single stream per camera to get out there.
• High H.264 compression. I've seen 4CIF streams compressed to 250kbits without issue at 10fps. That's more than plenty to get the job done, even though details will be compressed out.
• Speaking of compression, use a constant bit rate! CBR will handle this much better since VBR will spike your upstream unexpectedly.
• Look at a streaming appliance hosted in a datacenter. Datacenter rackspace can be had for $99 a month for a rack unit, including bandwidth. You hit the nail on the head with your own statement, this is a great way to offload the traffic.

As far as I understand, your initial statement about the VMS having one stream and reformat as necessary is not available in the market right now. You're asking for something called transcoding, where the VMS would decode the stream and reencode it on-the-fly to the clients. The processing power required to this is is very heavy, which makes it very expensive to implement.

Good luck!

Bohan, the problem is the lack of bandwidth. Unless you, as Seth suggests, change the link, you have less than 1Mb/s to stream 8 cameras to a VMS on the other side.

But they would need to serve that 1 client all 8 camera feeds at all times.

Sending 1 client 8 streams is pretty much the same thing as sending 3 clients, 3 streams each (8 v 9).

If they are only getting 0.5fps, the issue is likely the compression or video settings on the DVR, which would not be resolved by adding a VMS.

My gut feel is that replacing the DVR with a system that is better to optimized for low bandwidth remote transmission would be the best solution (assuming no multicasting and the link cannot be increased).

Sorry I wasn't clear at the outset.

When supporting only a single client, we get about 5 fps each on all 8 low def, low quality analog cameras, and that's sufficient.

If we could get that 8-camera video stream to a central, well-connected server and re-distribute from that point, it'd meet our needs.

There's nothing magical about the DVR, so if it doesn't support RTSP we'd consider another option.

Thanks for all the help and support -- I'll provide feedback (it'll be a while on my schedule) but it sounds like we can get Milestone or Luxriot approaches to work.

Thanks for the updates. So far we've ignored the problem hoping it will go away. It hasn't :)

Here's what we have:

. /-------------<same adsl>------(client)

8 cam dvr--------------<same adsl>------(client)

. \-------------<same adsl>------(client)

Here's what we think we need:

. /--<same broadband connection>---(client)
8 cam vms ---<adsl>--> something smart --<same broadband connection>---(client)

. \--<same broadband connection>---(client)

Hope font width makes that intelligible.

The rural location makes alternatives prohibitively expensive. We already burn about $6,000/year for a Verizon package of dual phone lines and adsl internet. The internet is connected only to the ADT DVR.

I'd like to thank everyone for the suggestions and for expanding our technical knowledge. Our sense from these comments is that we could use Milestone or Luxriot to ingest RTSP stream(s), sent only once across the limited bandwidth, and support multiple clients at the VMS end of the link.

In my ignorance, I'm unclear about how Ocularis might support or effectively supplant our imagined architecture. Our critical limitation is exfiltration bandwidth, so we want to exfiltrate once and then distribute to desired users from the business FIOS end. Business FIOS is practically unlimited bandwidth as far as the security application is concerned.

Again, thanks for all the comments and helpful suggestions. This hasn't been our priority because our business has so many wolves at the door. We hope to "get to it" soon.