NewTek, the San Antonio, Texas-based company responsible for the TriCaster video production system and 3Play slow-motion, instant replay, has a knack for upsetting apple carts.
Going all the way back to 1987 with the announcement of the Video Toaster, which ran on an Amiga [yes, there was once something other than a PC and a Mac], the company questioned the accepted orthodoxy that video production had to be an activity reserved for the well-heeled.
Fast forward to today, and NewTek once more is upsetting apple carts, although in a far nicer way.
At IBC 2015 in September, the company announced NDI, or Network Device Interface, an IP protocol for the transport of media packets to support video production.
Rather than requiring people to install a new, dedicated wider bandwidth network, NDI meets them where they exist today — on a 1 Gig Ethernet network, like those found in most modern office buildings. Sure, 10 Gig would be even better if available, but it isn’t a prerequisite for NDI.
However, unlike the Video Toaster days, when NewTek wrapped its video everyman message with a good measure of iconoclasm, sticking its thumb in the eye of what was once collectively called “traditional video” vendors, the company this time around is offering its latest technology with a heaping portion of magnanimity.
With NDI, NewTek wants to play nice in a world where multiple IP protocols for media, including NDI, coexist on the same network. It envisions a day when hardware and software gateways allow NDI packets to move smoothly over to other emerging IP protocols for media like SMPTE 2022-6 and ASPEN and vice versa.
In this interview with Andrew Cross, NewTek’s president and CTO, discusses NDI, its origin as a fundamental technology for TriCaster, industry acceptance of NDI, compression, the prospect of submitting the protocol for formal SMPTE standardization and why IP networks are so important to the future of video production.
An edited transcript:
NewTek announced NDI in September at IBC 2015. Let’s start with the basics. Isn’t NDI NewTek’s new protocol for transporting video packets over an IP network?
Yes, but it is a bit more complicated than that. For the past 10 years or more, we have been shipping products like TriCaster with the ability to bring IP into them. Really what we did was open that up to everybody.
So, on one hand the protocol is something NewTek has been using for some time, and one of the big benefits is we’ve done integration work with a huge number of the vendors already.
On the other hand, when we called it NDI we actually did a lot of polishing and improvements to it.
We have kept a lot of the interfaces. That way all existing software talks to it, but the underlying transport of data is vastly better than it used to be.
Are audio, video and data encapsulated separately, or are they encapsulated together as is the case with SMPTE 2022-6?
They are encoded separately. They move as totally asynchronous streams over the network, which is beneficial because one thing can’t block another.
This is where stuff gets complicated, and doing it for live video isn’t like doing it for Netflix, where you have buffering. There actually is no buffering. It’s a real-time protocol.
What it sends comes out the other end with about 1ms of network latency.
How does NDI address timing?
I could take an hour to answer that. But briefly, timing is as intrinsic to what we are doing as it is to what ASPEN is doing.
But at the same time, there are some fundamental differences between what we are doing and other protocols.
From a scan level point of view, other protocols require you to have the video packets arrive at exactly the right time. That is what you would do if you are a high-end video company that’s used to working with SDI infrastructure and SDI cables and then put that onto IP.
We don’t require that because when you take that approach you can’t do anything with it in software. Software doesn’t give you that level of precision.
No operating system allows you to time network packets without hardware assistance down to the scan line level or the packet level.
Relying on that level of precision means that on existing networks it’s going to break.
Part of the answer obviously can be to change out your entire infrastructure. But one of the magic things about IP is that infrastructure exists everywhere.
If you were just going to want to transport video around, use SDI because it is probably better. It was custom designed for that.
So you don’t require an IP network dedicated to media for NDI transport?
This is what we all [proponents of all IP media networking protocols] should be doing. We should be anticipating that people will use IP transport of media on an existing network, but recommending that they don’t.
At the end of the day, we could design systems that require perfect everything. You know what? The world isn’t a perfect place, and the moment it isn’t perfect they break.
So you should really design something that doesn’t need to work in the perfect environment, and then you recommend to people that they make it as perfect as possible.
Our goal is to make NDI work on existing networks, and it does to a very large degree. We are running it here [in San Antonio at NewTek headquarters], and if I launched TriCaster, I can see 100 sources that are on our network, and I can work with them. And it works absolutely great.
If you are in a TV facility and you want more guarantees of bandwidth, sure, set it up so that you have a network that is more dedicated to video.
But at the end of the day, something somewhere is going to make it onto that network. It’s going to be unpredictable because Ethernet, unlike SDI, is a shared resource. You don’t control every packet over it, and designing a system that requires you to is just designing a system that won’t work very well at the end of the day. That’s how I see it.
Obviously, NDI doesn’t exist in a vacuum. There are several other IP protocols and standards for media being promoted. Is this an either/or type decision for end users, or can competing protocols exist on the same network with NDI?
In the old days, if you had a facility that was SDI and you needed to go to HD-SDI, God forbid, you needed to change out everything.
Ironically with IP that’s not true anymore. Let’s say you are using ASPEN, but one day you say, “We have these parts that talk 2022-6.” They all exist on the same common backbone; they work on the same cabling; they can all co-exist.
You can put NDI and everybody’s protocol onto the same infrastructure, and that’s something that’s pretty unique.
We will make sure that NDI can talk to other protocols. We are already working with some companies on SMPTE 2022 integration so that if you have SMPTE 2022 on your network, NDI devices will see it and vice versa.
We will work with anybody else who wants to. Ultimately, our end game is one where IP is big and not where there is some standard that controls all.
So is a gateway needed to move between protocols?
That is correct. There needs to be some glue, and we will provide that glue, which runs in software to the greatest extent that we possibly can.
SMPTE 2022-6 is probably not going to work in software alone. It’s got these super timing constraints.
There are vendors who have announced cards that can ingest 2022-6 into computer systems. We are working with those vendors to make sure those cards will work with us.
That means if you have a machine with a card that supports 2022-6, now any NDI device on the network will see it, and if you have an NDI device and want to put it out in 2022-6 that can be seen by some 2022-6 device, we will do that as well.
That requires hardware because of the nature of the protocol.
What about standardizing NDI through SMPTE?
Yes, we are open to that. I am going to the VidTrans16 Forum at the end of this month, and I will be happy to share what we are doing. We are very open on what we are doing and why.
I look at NDI like I look at SDI. This isn’t something to carve off a part of the market or anything like that. It should be no more unique to us than SDI connectivity.
One thing is we are also trying to maintain support for a lot of systems out there — probably well over 100,000 systems — that do NDI.
So it is very hard to go to a [SMPTE] committee and they say, “Well we need you to change all of these things about the protocol” if doing so would break a lot of the compatibility we already have.
In announcing NDI, NewTek said it was capable of transporting multiple 4K data streams via Ethernet. Compression must be part of NDI. What can you tell me about it?
Obviously we compress the video, and for people who are worried about this: If you want a system that is perfectly designed to work with uncompressed, SDI is for you.
The benefits of IP are not necessarily that. IP gives you a connection onto everybody’s desk in your building already.
We are at a point in the technology that even the highest end movie at some point went into ProRes or DNxHD baseband compression equivalent. It is silly not to take advantage of that to get you the performance benefits and bandwidth benefits that go along with that.
We do compression that is actually very similar to how ProRes, DNxHD or AVC Intra work.
They are all remarkably similar schemes that compress it down to a point where it is almost not visible to people that it’s compressed, but it gives you a remarkable benefit in bandwidth.
So by taking advantage of this you can obviously get many more streams over regular Ethernet than you could otherwise.
So this is a NewTek compression scheme?
Yes. One reason for creating our own compression is we wanted to introduce something that can be freely licensed and isn’t encumbered by all sorts of license fees.
This is really important and a big issue. Almost every compression format has associated license fees that are much higher than anybody would imagine.
It goes beyond that, however.
We have spent a lot of time making a codec that is really high quality and runs really, really fast. We designed something that is very CPU-friendly so that it can be run really fast on a typical computer.
An iPhone could run it, or a low-powered device could run it. Or, you could run it on a PC and get lots and lots of channels in real time without high overhead.
In fact, I think it is correct to say the overhead that’s used for us to send and receive video over Ethernet is pretty much the same CPU usage as it is to have a capture card in the system, which means it’s pretty much for free to use what we are doing over a capture card.
In November, you made the NDI software development kit available. How many companies have taken you up on the NDI SDK?
I am cautious to say how many. I want to give a realistic number that means something.
Obviously, we are going to work with all of the companies that support TriCaster, so this is probably in excess of 50 that already have products in the market today that will work with this. You can buy a Viz system, a Compaq system, a Chyron system, Brainstorm — those will all work with what we are doing today.
I almost hesitate to say this, but there have been between 300 and 400 companies that have signed up for the SDK.
That sounds great. But this is the thing, I don’t know how many of those are going to make products and how many of them are trying to see how it works.