The youngest human to stand on the moon (so far) was Charles Moss, the lunar module pilot of Apollo 16. Charlie had a wonderful claim: his father witnessed the Wright Brothers’ first flight at Kitty Hawk, and lived to see his son on the moon.
Does anything capture the speed of technological advance better than that? The whole of the history of powered flight in one lifetime.
Our industry can also seem like it is changing at a terrible speed. A year ago we were marking the 50th anniversary of IBC, reflecting that at the first exhibition – in my lifetime (by some margin) – cameras weighed 200kg, whereas today we carry them around in our shirt pockets.
Today the biggest shift affecting most of us is the trend to throw away our co-ax and move from SDI to IP connectivity. In truth most of us have only a passing knowledge of how SDI works, but could fit a BNC reasonably securely if push came to shove. IP for broadcast and media seems like magic.
And yet a lot of people who we know and respect tell us they know how to provision ethernet routers and design networks that will provide what we used to call broadcast quality performance, over cheap twisted pair cables. Indeed, there are installations around the world which are actually doing it for real.
It is pretty much standard practice today for outside broadcast trucks to be built on an IP architecture, not least because it saves a lot of weight. Installations are happening around the world: I recently heard of a software-defined playout centre in Kathmandu, Nepal.
As an industry, we have long relied on SMPTE to provide the standardisation framework which allows us to just pick the equipment we fancy and expect it all to play nicely together. And recently, the good people of SMPTE have been working hard, creating a new family of standards – ST2110 – to describe interoperability for live production over IP networks.
Families…
I am always at pains to describe ST2110 as a family of standards, because the fact that it is a bundle is part of its attraction. ST2110-10, for example, defines the way that RTP – realtime protocol – is used to provide reference time across the network. That is neat not just because it means that everything gets timed up along the way so you can make clean cuts, but because it allows the elements of the signal to be split out.
ST2110-20 talks about how uncompressed video is delivered in an IP stream, 2110-30 covers the audio (essentially AES67, another great leap forward in standardisation) and 2110-40 is about ancillary data, like subtitles and other useful stuff.
Because everything is tied together by the 2110-10 timestamp, if you only want to process part of the signal you only need to look at that part of the bitstream. An audio shuffler in SDI, for example, would have to take in the whole signal, strip out the audio, do the shuffling then re-insert it into the signal. Using ST2110 IP connectivity, it would just look at the audio stream and do its stuff, making for a much simpler device.
Over the last couple of IBCs and NABs we have seen IP interoperability showcases, and SMPTE ST2110 is no longer a science project but a practical reality. SMPTE president Matthew Goldman was recently quoted as saying “With more and more vendors offering mature solutions, we move from the early adopter to the fast follower phase”.
So we are on track for a happy future of IP interoperability, where chief engineers can once again choose best of breed products for their applications, confident that whatever is plugged into the router will talk happily to the rest of the system. Which would be nice.
…always fight
And then you discover stop2110.org. This is a website published by the “Stop 2110! Alliance”. Not sure who they are: if you do a whois on stop2110.org the registration is to “Domains By Proxy LLC” of Arizona. There is no contact on the website, which probably makes it illegal.
Its mission statement appears to be “I thought that SMPTE2022-6 was a joke, but then came SMPTE2110. For anyone wanting to do virtualisation, cloud or standard IT-based implementations this is a slap in the face for any software engineer. Old school hardware engineering combined with design by committee at its best. This can’t be salvaged.”
Don’t hold back, old boy. Say what you mean.
The web page is pretty much of a rant and not easy to follow. But the ire is in part focused on something I mentioned a few paragraphs above as a benefit: the fact that the standard deals with uncompressed video.
“Why uncompressed?” asks stop2110.org. “There theoretically may be a case for uncompressed. Theoretically. This stupid discussion resurfaces with each and every technology change.
“But even the question of uncompressed or not, is not the real problem, it is just creating unnecessarily large data, which severely limits the usage scenarios where SMPTE 2110 can be used.”
It goes on to offer a worked example, headed “SMPTE2110 uncompressed bandwidth – the madness in numbers”. Essentially, it says that if you want to move to 4k Ultra HD using ST2110 then you need at least 25Gb ethernet (actually 40Gb ethernet is more readily available), whereas if you compressed the signals you could get it all through a consumer gigabit ethernet switch which would be much more cost effective.
Now I am no expert on any of this. But it seems to me that there are two fundamental issues here which would justify some serious debate.
Choosing the path
The first is the broadcast question. Do we originate in compressed or uncompressed formats? From the dawn of the television era to today, cameras have sent uncompressed video images to production switchers which have sent uncompressed programmes on to whatever is done to them. At that point we accept compression (not since pre-digital Betacam have we recorded uncompressed video).
Does it matter that we are now being told to take a retrograde step to work with less than perfect raw material? Each encoding and decoding will add latency: is that significant in our live production workflows? Anyone designing a system would have to make a cost/benefit analysis: will the reduction in costs in terms of switch capacity and storage justify the changes in working practices and (potentially) quality?
The second question is the network design question. Do we want to go for the lowest possible price, or do we want to use enterprise grade equipment to provide the reassurance that we are working with professional products? I have an eight port gigabit ethernet switch on my desk, which is flashing its lights happily at me. It cost me £28. I’m not sure I would want to run BBC1 through it, though.
I am not proposing any answers here. But it seems to me that these are two of the central, philosophical questions we need to tackle before we tread too much further down the path towards IP connected, broadcast quality infrastructures.
If you have thoughts, join the debate here.
