Are broadcast engineers and IT engineers living together in harmony?
You’re likely aware (or perhaps you aren’t, in which case time to put your school hat back on) that at the heart of ‘the internet’ lies two central transport protocols: UDP/RTP and TCP. All other elements of the internet rest upon these two TPs (transport protocols), so understanding their differences is pretty crucial. And as with so many things, those differences come down to two central elements: reliability and speed.
UDP/RTP is the quick but messy version, whilst TCP is the insistent and pedantic but sluggish version. The difference is often best summed up in two popular programmers’ jokes: ‘I wanted to tell you a joke in UDP, but I’m not sure you’ll get it and I don’t really care’, versus ‘Here’s a TCP joke. Did you get it? Did you get it? Did you get it?’.
And the vastly different capabilities of these two transport standards excite the passions of two vastly different groups of people; namely, broadcast technicians and IT technicians. For all too long, IT technicians – and their Telco overlords – saw the world largely through the lens of HTTP and TCP. The latter – with its guaranteed checking of packet delivery – ensured that users received the contents of their static webpages in the right order, and it didn’t really matter if it took a few extra seconds to arrive. Anything else that was needed more quickly – such as video – had to be left to the vagaries of UDP/RTP, and a ‘best effort’ approach meant that data was sent off into the ether with fingers crossed, hoping there was enough ‘space in the pipes’ for it to get through, ideally in the order it was sent.
But as broadcasters sought to leverage the huge potential of IP, things started to change. The ST2110 opened the gates for video to make use of the speed of UDP/RTP, but control for the packet loss and disorder that come with it by ordering the way that packets are sent in a way that is much more manageable, taking account of bandwidth and buffer availability. Broadcast engineers started to use IP in a way that left traditional broadband engineers scratching their heads.
And this somewhat oppositional approach to the use of the same virtual space marked the state of play for some years. But increasingly that mentality has changed, and we’re seeing much stronger interaction between the ‘two sides’; with mindsets converging and collaboration marking the relationship between the two. Telcos are getting in on the broadcast game – and they’re borrowing from the vast pool of knowledge that IP-based broadcast engineers have been developing over the last two decades. Engineers like ours here in the Bridge offices.
One of the big mindset shifts that IT engineers are having to adjust to is the idea of compromise – and the idea that it has no place in video delivery. Traditionally, the relationship between reliability, speed and quality were viewed as a triangle which could be manipulated to prioritise two sides of the equation, and never more. But as the broadcast market became increasingly competitive and audiences increasingly discerning, broadcast engineers recognised that they could no longer afford to just change the skew of the triangle; the triangle simply needed to be made bigger and better. No tradeoffs of reliability for speed or quality for reliability – just sweeping improvements across the board. For IP to push the boundaries it has promised to for so long, it needs to deliver high quality broadcast, in real-time, with no dropped packets, no latency: nothing that could detract from the audience’s viewing experience.
So whilst in the IT world there was still a tendency to rely on legacy systems and structures to do increasingly more complex tasks, in the broadcast world engineers were getting creative – tearing down old ways of thinking and innovating relentlessly. It’s this kind of mentality that leads to big jumps in the progress that broadcast-focused engineering is making.
And it’s this mentality too that has led to the development of our own products at Bridge. The ST2110 standards (including their expansion into the realm of uncompressed production) do remarkable things in taming the vagaries of an underlying UDP/RTP transport structure and making it work for video – but it isn’t perfect. As a result, real-time, in-depth analytics and monitoring that give meaningful insight into network performance are vital; for broadcast and IT engineers alike – ensuring that video gets where it’s going, in the way that it’s meant to.
Indeed, we’d say we’ve been fairly fundamental in ‘bridging’ (sorry) the gap between the two factions, and indeed between engineers and non-engineers in a general sense, by translating our 20 years of IP insight into a message and a product that makes sense even to the non-technical; intuitive in its visualisations and capable of delivering information that allows for both in-the-moment adjustments (either to fix errors or, in the case of the VB440, to inform creative decisions), or long term strategic decisions taken at the board-room level.
Our membership of SMPTE and AIMS is indicative of exactly that collaborative mindset, where IT-based broadband engineers are starting to engage more directly with broadcast professionals, and are coming to understand the dramatically different needs that IP-based video delivery carries with it as compared to other data forms. Through this understanding of difference, shared ground becomes easier to find – and the wonderful events that SMPTE host certainly help us all to navigate that ground together. And speaking of living together in harmony, a perfect example of this collaborative mindset is our participation in the upcoming JT-NM (Joint Taskforce of Network Media) event from 22 to 26 August.
