Member Discussion
Remote Viewing Bandwidth Limitations?
We wish our system would forward a single video stream from each device, local or remote, and then reformat as necessary to accommodate each client stream request. For example, the VMS would respond to requests and as necessary output one best quality stream for the video wall, other lower quality streams to iOS and android mobile device requests, and perhaps others for port 80 HTTP requests, as appropriate to whichever clients were active and requesting streams.
Our experience is based upon an austere location 8-camera ADP local DVR with remote RASPLUS viewers across Verizon copper ADSL, with uplink (video exfiltration) rates averaging well below 768 kbps.
The central office is not bandwidth limited. There is always a remote viewer active at the office, and occasionally up to two ios devices somewhere in cyberspace also remotely viewiwng the active video.
With remote exfiltration as the limiting factor, ADP's solution has been pretty suboptimal since the DVR handles remote streams independently, completely saturating the ADSL uplink and delivering a frame every 2 seconds or worse, with occasional lock-ups.
The "A" in ADSL doesn't help, since we use the internet exclusively for video exfiltration yet 80% of the ADSL capacity is in downlink, which is used only for external interfacing with the DVR and for packet acknowledgements, etc.
We'd like to exfiltrate each camera video stream once, to a remote VMS at a well-connected location. Then the VMS should support all viewing requests, whether local or across the internet (such as iOs, etc.).
Our feeling is that ADP (or at least their local franchise) didn't really understand how to design an effective system within a link-limited environment, or else maybe all they had was a hammer (ADP DVR with RASPLUS remote viewers) and so every problem was treated like a nail. At $6K for eight cameras, we've really come to regret going with the security market leader on this install.
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.
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.
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%.
Bohan, my point is that the VMS will need to continuously request all 8 streams from the DVR because it does not know when nor which streams a client may request. To the extent they ingest all 8 streams, it will be negligible bandwidth savings compared to a 3 client / 3 stream situation.
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.
Newest Discussions
Discussion | Posts | Latest |
---|---|---|
Started by
John Honovich
|
16
|
1 minute by Undisclosed Manufacturer #4 |
Panasonic VMS (Video Insight) Refuse To Fix A Software Playback Issue Unless Users Pay To Upgrade
(21)
Started by
Undisclosed Manufacturer #1
|
21
|
about 2 hours by Undisclosed Integrator #4 |
Started by
John Honovich
|
13
|
about 2 hours by Undisclosed End User #7 |
Started by
Undisclosed Manufacturer #1
|
5
|
less than a minute by Undisclosed Manufacturer #2 |
Started by
John Honovich
|
7
|
29 minutes by Shannon Davis |