The Pace of Change


Dick Hobbs - new TV-Bay Magazine
Read ezine online
Download PDF
Download PDF

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.


Tags: iss133 | state of the nation | st2110 | st2110-10 | Dick Hobbs - new
Contributing Author Dick Hobbs - new

Read this article in the tv-bay digital magazine
Download PDF
Article Copyright tv-bay limited. All trademarks recognised.
Reproduction of the content strictly prohibited without written consent.

Articles
Accelerated Workflows with eGPU
Mike Griggs From the UK’s National Trust to magazine publishers to manufacturers, digital content creator Mike Griggs has a wide and varied portfolio of clients for whom he creates 3D art, motion graphics and multimedia exhibits. A typical day might involve sampling birdsong near Virginia Woolf’s country estate or creating 3D animations for VR. To keep on top of these demands, Griggs wanted to take the full power of the GPU computing revolution on the road.
Tags: iss134 | sonnet | egpu | amd | post production | editing | Mike Griggs
Contributing Author Mike Griggs Click to read or download PDF
Giving Welsh sport a global audience
Adam Amor From the Ospreys Rugby Union team, to the Football Association of Wales, as well as national cycling, swimming and boxing coverage, Port Talbot based Buffoon Film and Media has been heavily involved in putting Welsh sports on the world stage.
Tags: iss134 | blackmagic | atem | buffoon | micro studio camera | Adam Amor
Contributing Author Adam Amor Click to read or download PDF
Keeping it remotely real
Reuben Such Everyone wants to do more with less. Always have, although it could be argued that doing more with more is something to aspire to, not many have that luxury. So let’s stick with the prevailing winds of doing more with less, and not just doing more, but doing it remotely, particularly in terms of production. Remote production, in particular, is getting a lot of attention in the field these days, but not so much in terms of the remote operation of fixed studios.
Tags: iss134 | remote control | IPE | IDS | Reuben Such
Contributing Author Reuben Such Click to read or download PDF
What content providers need to know about OTT
Hiren Hindocha As OTT (Over-The-Top) technology has gotten more mature and established robust standards over the years, the concept of OTT monitoring is gaining popularity. With customer expectations soaring, it’s vital for OTT providers to deliver superior quality content. To deliver Quality of Experience (QoE) on par with linear TV broadcast, the entire system, starting from ingest to multi-bitrate encoding to delivery to CDN must be monitored continuously.
Tags: iss134 | ott monitoring | qos | logging | compliance | dash | atsc | cloud | Hiren Hindocha
Contributing Author Hiren Hindocha Click to read or download PDF
An Obituary to Timecode
Bruce Devlin - new A stoic and persistent character that stubbornly refused to change with the times, Timecode has finally passed on, but no-one has noticed. A long-lasting industry veteran, Timecode was brought into this world at an uncertain date in the late 1960s due to the needs of analogue tape workflows and the demand for synchronisation between audio and video devices. A joint activity between SMPTE and the EBU led to the work on Time and Control codes starting its journey to standardisation in the early 1970s.
Tags: iss134 | timecode | smpte | ebu | edit | Bruce Devlin - new
Contributing Author Bruce Devlin - new Click to read