Continued from  part 2

NDI

Alongside this rush to hardware, there is a contrasting and more pragmatic approach where the layers of existing standards are skipped and a purely practical solution for getting a frame of video from one device to another has been sought.

Enter Network Device Interface (NDI). This has been designed with a number of important prerequisites in mind, and offers a practical solution for IP Video which can work on existing 1Gbit network infrastructure, or even Wi-Fi, without the need for dedicated hardware.

NDI is offered as a licence free technology with a very easy to implement API. Tools based on NDI have already been demonstrated on a variety of platforms. NDI can be comfortably implemented in software, with demands on compute so low that applications for iPhone and iPad are already available - something which would be impossible using SMPTE 2022–6 or ASPEN.

Designing a system that can be built on commodity gigabit networking infrastructure is a key requirement. The cost benefits alone of standard gigabit Ethernet over copper compared with fibre based 10 gigabit networks make it a clear and obvious goal.

In order to use Gigabit networking for HD Video, compression is essential, and NDI includes a high quality wavelet codec as part of the solution, yielding a typical data rate of 50-100Mb/s per stream. Unlike H.264 the NDI codec does not carry any licence fees, and is designed to be very low latency. It is also extremely efficient, and a typical modern desktop computer can easily compress HD at full frame rates on a single CPU core, providing the multi-channel scalability needed for more ambitious systems with multi-core CPUs. NDI uses the TCP Protocol to move entire compressed video frames in one piece between software based systems without the requirement of dedicated hardware to compress, decompress, slice, dice and interface with 10 gigabit networks.

Which Protocol is most suitable for each application?

We have outlined three different IP Video solutions – and there are others that we have not mentioned. Much of the industry discussion has revolved around ‘which is best’ — looking for a single IP Video protocol ‘to rule them all’. However, in fact, it turns out that broadcast almost certainly needs more than one IP Video protocol, and we need to start thinking of IP Video as a family of protocols, not just one. To illustrate this, we will look at four fundamental connections found throughout the broadcast chain:

1) Hardware to Hardware (e.g. camera to router or router to monitor, long distance carriage of SDI over fibre)

2) Hardware to Software (e.g. camera to ingest software)

3) Software to Hardware (e.g. playout software to router)

4) Software to Software (e.g CG, DDR, cell phone camera — anything interfacing with a software based vision mixer, and many future directions for integrated workflows)

We have four different junctions, each of which might traditionally have used SDI in some way, or in the case of 4) Software to Software, it might have required SDI hardware adaptors on both ends simply to get from one piece of software to another.

As devices traditionally viewed as ‘hardware’ evolve, more and more of these components will actually become more like ‘software’. For example, a network camera ceases to be a purely SDI device and starts to become a piece of IP Video software capable of so much more. Vision Mixers are gradually shifting from expensive hardware based devices to become more software driven systems. Even video monitors have a changing future — rather than routing one signal to a monitor — let the monitor pick up the one it wants up from the network.

Whilst Software to Software systems may be a minority today, it is clear where the future leads, and so it’s worth considering the optimum IP Video solution for interconnected software. As described in the earlier sections, SMPTE 2022–6 and ASPEN both employ very high data rates of very complex bit streams and as such are not suitable for a pure software to software exchange of video frames. In contrast NDI (which was specifically designed for software to software communication) provides a low overhead, manageable bandwidth, and ultimately *simple* mechanism to pass video and audio from one piece of software to another.

Conversely, in pure Hardware to Hardware systems, which are already based around underlying SDI architecture, clearly a solution like SMPTE 2022–6 or ASPEN may be most appropriate.

The ultimate conclusion is that we almost certainly need more than one IP Video standard - and we should not been looking for just one solution. We need to evaluate the four different interface classes between software and hardware and consider the best fit for each. In doing so we can create the most efficient and practical approach to the adoption of IP Video, and maybe somewhere along the line we can start to see the real benefits and opportunities it promises.

Mark Gilbert is CTO at Gallery SIENNA. Simon Haywood is an independent broadcast consultant at Tamed Technology