To answer some of the questions posed in this thread:
Data rate : NDI.Cloud supports a range of around 2mBits to 20mBits per stream. Realistically you will need 4 or 5 mBits for simple HD scenes, more for complex HD scenes.
How: NDI.Cloud creates a software defined video network which links NDI.Cloud gateways in each LAN location and uses them to pass NDI signals in each LAN via the internet (as H.264) then back to NDI at the other end. The user just sees remote NDI sources as if they were local.
So - you need an NDI.Cloud Node Gateway computer in each LAN. This can be a Mac, Windows or Ubuntu machine.
There is a full explanation of this in the NDI.Cloud Wiki at
http://ndi.cloudBuying: NDI.Cloud is a service involving a cloud based collaboration server (to configure and connect up your sites) and downloadable Gateway software. It will be free for a public beta period, and once launched a monthly subscription based on the number of sites you have. It will be very affordable for any professional video user. Rather than charging thousands of dollars for a hardware box each end to carry one stream point to point, NDI.Cloud offers a low cost monthly subscription instead which is much less expensive and allows unlimited connections between all of your nodes (subject to available bandwidth and computing power). The infrastructure is software defined so you can 'spin up' new nodes at different locations by installing software on any available computer, even via remote access. This is all exciting new stuff to drive fresh global workflows.
Latency: One objective of NDI.Cloud is to limit latency. We use a very low latency H.264 software encoder, but there is a necessary buffering stage at the receiving end to smooth out the lumpy internet. The final latency is controllable based on your needs of required smoothing and the quality of your internet connection (regular packet loss will require a longer smoothing buffer). In early tests with the buffer set to zero we were able to move video between continents with around half a second latency.
In real use with audio we expect the latency to be between half a second and 2 seconds depending on settings, connection quality and environment.
We are going to recommend a smoothing buffer of around 2-3 times the connection ping-time. If you can accept the odd glitch or dropped frame you can potentially reduce the smoothing buffer to optimise latency. The point is that you have control over all this.
Another important point is that NDI.Cloud will support multicam sources with the same latency so you will be able to backhaul multiple cameras and then switch them elsewhere without worrying about mismatched latencies. The signals are sent from the same box (e.g. a TriCaster 8000) with coherent timestamps, then received by the same NDI.Cloud Node elsewhere which resynchronises the various streams (which have travelled independently over the internet) and they pop out in the LAN with the same relationship to each other.
Also, NDI.Cloud supports fill and key over the internet, something which is not possible with most existing solutions. Also, it can potentially support multichannel audio (its limited to stereo at present, for convenience so we aren't wasting bandwidth on ch 3&4 which are usually empty).
Testing: We are in private beta test at the moment, whilst we file off the loose ends and make sure the service is ready for the huge demand we see. Professional video folks with specific applications, and the networking experience, NDI experience, connectivity and available hardware who would like to contribute to beta testing can apply to join the private beta program. See the forums at
http://ndi.cloud for more info.
Finally - the whole point of NDI.Cloud is to extend the seamless NDI experience across the WAN. Its not so much about how its done - more about what the user experiences - all the remote NDI Sources appear in your local NDI popup menu - and that is all you have to worry about. The rest is done invisibly under the hood.
