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.
John, A quick update on the ONSSI web server software.
Ocularis X is out and Ocularis Media Server is the new kid. I have been testing with it in our lab lately to see what system resources it uses (mostly CPU due to the transcoding task).
It has a 'Server side' and a 'Web Client side'. The Server side grabs the desired streams (16 max per view) and encodes them into a single stream going out to the Web Client that requested the view. The individual mass stream bit rate is controlled from the Server side and can be from 1Mbit up to 16Mbit for that requestor.
The Web Client side uses Flash for viewing and controlling thus devices that do not support Flash are currently not supported. It uses a minimum amount of system resource of course.
Mike, thanks! What is the CPU load range for the server side?
What I observed is that it is a significant CPU hog due to the transcoding the system is doing. The thing that is nice to control is the Bandwidth to the Web client that I already mentioned.
For example, on an I5 based system, doing a 4x4 salvo would add 30-40% to the CPU for a SINGLE Web client. If a SECOND Web client is started...then that much more CPU is required.
In ONSSI documentation there is mention that doing more than 10 cams should be done on a separate system. I totally agree with this.
From the conversation, it seems that the professionals are understanding this discussion, but I'm still missing pieces.
Can you explain what is the individual mass stream bit rate? Is it single camera's single feed, all cameras encoded and exfiltrated in a single stream, all possible gozinto/gozouttas of the system, or something else?
Also, I must be slow, because this discussion has not helped me understand the proposed system architecture.
I envision all 8 cameras feeding an on-site client. Is this client expected to be ocularis media server?
Then I envision a single stream of all 8 cameras at 1 CIF and whatever supportable frame rate exfiltrated over an austere link to a remote, well-connected location. What would be at this remote priviledged location? Another Ocularis media server? A web client?
Then I envision all valid users having arbitrary access to any parsed elements of those feeds. I expect that would be an arbitrary number of web clients "out there."
I appreciate your patience. Clearly I don't have enough experience or knowledge in the field to grasp these quick back-and-forth discussions which seem to assume a great deal of embedded knowledge already exists (perfectly appropriate to an IPVM forum; sorry I don't measure up :)
The mass stream rate... "all cameras encoded and exfiltrated in a single stream"...and the sys admin gets to pick the rate to this single mass stream (1Mbit to 16Mbit).
The ONSSI doc on the Media Server has a nice diagram of how it envisions the MS to fit into a system in figure 1 on page 2...attempted to show below.
The way one 'sizes' an Ocularis system is to estimate or know what sort of overall bitrate is being handled by the various functional blocks shown in the diagram. If it is determined that a particular function will use a significant amount of resource...then it needs to be considered as a separate system unit.
Your cam streams come into the Recording Server and they can be directed out to normal Clients and Web Clients. The Ocularis Client application pulls individual streams from the Recording Server. This Client application simply grabs the video feeds and does the transcoding AT THE CLIENT...thus a good system is needed to look at these streams.
The Media Server will collect all the requested 'web streams' from the Recording Server and downsize+change FPS+reEncode to make a single stream going to the requestor. Doing this takes a good amount of CPU resource.
Note... a Second and Third Web requestor of the same number of streams as the First will double and triple the CPU resource because it has to repeat the chores for all the requestors. For example... if a 3x3 salvo uses 25% of a particular system CPU.... then three Web calls for this same salvo will use 75% of the CPU.
In general, the client related applications in a VMS will take as much or more CPU/GPU resource than the strictly recording part. This is why most mainstream VMSs recommend that users do not do a significant amount of viewing on the systems that are recording the video data.
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 |
