Remote Viewing Bandwidth Limitations?

Horace, your application is tough and I am not sure what easy answer or alternative exists.

As you note, with only 768Kb/s upstream, you are severely constrained in streaming video to remote clients.

When multiple viewers simultaneously request video, that link will surely be overloaded.

You could evaluate using multicasting but that might require a different recorder/system and that Verizon network may not even support it.

Alternatively, as you suggest, you could have a VMS / transcoder / replicator on the other side of the ADSL connection that takes in video and then copies / adjusts the stream for multiple remote clients. However, I am not sure of a commercial product that could do that dynamically. You only have 768Kb/s, so you don't have enough bandwidth to even send a single stream up for each camera (unless you dramatically reduce its quality/frame rate, etc.).

With 768kb/s uplink and multiple viewers, a frame every 2 seconds is not unrealistic. What's the resolution at? CIF, 4CIF, 720p, etc.? You can likely increase the frame rate by reducing the resolution (not that that's a great option).

OnSSI has Ocularis X which will transcode and stream up to 16 HD streams over a t1, full frame rate. I've seen it done but never had to deploy on a t1, so who knows...?

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!

As long as that DVR allows access to streams via RTSP URLs there are many VMS that will do the retransmission to remote clients inc phones in the way you want.

Milestone with the Universal driver and Luxriot with with Generic RTSP Compatible driver are two I personally use on a monthly basis.

John: from what I read the problem is that the DVR is sending 3 separate streams to 3 clients and the effective bandwidth is hence 1/3.

If they rang a VMS at the remote central location then the DVR would only need to serve 1 client - so there would be a improvement.

On 700kbps they should be able to do 8 channels at CIF/5fps, or 20ch at CIF/2fps. This is better than the 0.5fps they are currently getting.

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).

John: They have a central location with good upstream bandwidth. if they run a VMS here and connect the VMS to there remote DVR, the VMS will take only a single stream from each channel on the DVR and replicate it 3 times at the central location to send to the clients. they have hence cut the upstream bandwidth requirements for the DVR side internet connection by 60%.

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.