Interoperability ≠ Open Specification ≠ Open Standard ≠ Open Source
Setting industry standards is no easy process, but a successful outcome helps everyone.
The point of having standards is to enable interoperability. Apparently, just like new math introduced some different and often confusing concepts, the broadcast and production industries seem to have to have redefined the term interoperability.
The whole point of having standards is to ensure that a device purchased from vendor A will properly work with a device from vendor B. I wrote about this issue in my article, “AIMS versus ASPEN – The Next Format Battleground?”
Apparently, just as new math introduced new concepts, some vendors closely involved in developing IP solutions want to redefine the meaning of interoperability. For instance, within one manufacturer’s product line, different versions of their devices cannot communicate with each other requiring the signal to be returned to SDI to pass video between devices. So where is the interoperable part?
I have received only positive feedback on my recent articles as I attempt to create a “cause celebre ” on the issue. Unfortunately, some of the feedback comments state that more than one standard is okay, or one standard stifles innovation. In one instance a writer says, “we are all about interoperable and welcome everyone to support our standard”. What am I missing here?
Getting from all SDI to all IP may not be easy, but it will eventually happen.
Selecting an IP highway
So we have a little “my way or the highway” going on! At the same time we have two alliances, multiple standard organizations and two manufacturers each with their own competing technologies being promoted for adoption as a standard.
In one discussion, it was suggested a “grand summit” isn’t practical and one-on-one conversations make more progress. I guess we learned how well that process works with the ATSC Grand Alliance, where the outcome was 36 approved standards for HD video!
It has been suggested that some of the groups are at least talking to each other, which is encouraging. It was also suggested that there is an interest in coming to some common ground. So either they all need to work on their messaging or it’s not that far along yet!
Interoperable Standards | Non Interoperable Standards |
---|---|
RS170A | Beta vs MII |
CCIR-601 | D1, D2, D3, D5 |
SMPTE292M | SDTI |
802.3 Ethernet | MPEG1 |
802.11x Wi-Fi | MPEG2 first generation |
MPEG4 H.264/ H.265/HEVC | |
DASH/ON2 | |
DVCPRO/Dnx/ProRes/XDCAM/AVC/AVI | |
JPEG2000/MPEGTS | |
AIMS/ASPEN/NMI/NDI |
Interoperable standards are a bit of rarity in the broadcast and production community. That cannot continue in an IP environment.
IP solutions work
IP technology has been successfully implemented in live production environments. The first multi-camera IP broadcast happened. The EBU is working with Belgian broadcaster VRT to prove that IP can be a viable solution to the challenges of live studio production. Kudos to them and the manufacturers that cooperated to make it happen. Now if it can only be more than a one off experiment. Unfortunately, we have competing webinars and the lines are being drawn.
One of my biggest concerns is that this industry is still challenged by a lack of IT professionals willing to understand the basic of broadcast sensitivities. This industry wants to require the IP version of digital glue. But that “glue” is really software programming, API’s and middleware that will be necessary to integrate devices because of all these standards.
It is one thing to have a frame of cards and as the devices change the card doesn’t care. What happens if each time the standard changes or a manufacturer updates something, every piece of software has to be patched, updated or re-written? Such changes create a great opportunity for a programmer or a team of programmers. Maybe it’s a firmware update or upgrade. But in either case, both solutions are disruptive.
Of course there’s the other initiative EBU/AMWA - FIMS – The Framework for Interoperable Media Services. And where or how does this fit into the equation? In my discussions with EBU, this fits into the header of an IP stream essentially facilitating interoperability. This is really Session Layer 5 of the OSI model.
The current IP standards battle is for the Transport Layer 4 and how the stream moves through the network and maintains accurate sync with reference to the media stream. Today we call that Frame Accuracy. This is where “PTP” (Precision Time Protocol) becomes the new “Black”.
The LiveIP Project is a collaboration between the VRT, the EBU and ten broadcast technology companies. Image courtesy Sandbox.vrt.be.
So where does this leave us?
Sometimes the adoption of a solution is simply adopted because a company was first to the table with an answer. This only works if the adopted solution remains static long enough for people to adopt it. The recent EBU/VRT event used SMPTE 2022-6 and AES67 with PTP (is this SMPTE 2059) and Open Flow (what happened to FIMS?) However, while AIMS is claiming victory, it is also stating that it prefers VSF TR-04 and TR-03. That takes us back to square one.
Looking towards the 2016 NAB Show and anticipating there will demonstrations of products supporting live IP production, will it be like carnival barkers competing? Get AIMS over here, No ASPEN is the best, can I interest you in NMI? Hey there want to see my NDI?
Or will it be “Step right up and get TR-O4 with some 2059-1&2 or win the big prize and get upgraded to TR-03”.
Time to get serious again. Let’s talk NAB. I know of coming new products that will be based on NDI. The EBU/VRT team will be showing SMPTE 2022/AES67 with a path to VSF TR03/04 aka AIMS. The ASPEN solution will be exhibited in addition to NMI products.
The FIMS booth will be demonstrating interoperability. Everyone will be fighting for buyers and trying to convince stations and networks to invest their capital budgets in one particular solution. Everyone is hoping to get it right. Am I forgetting AVB? Wasn’t that supposed to solve these issues?
The dilemma resembles the original choice of 1080i or 720p. There will be a switch or some secret menu that lets the user select which protocol to use? Or maybe it will be auto detect.
I am thinking of a new business opportunity. Maybe it’s time to open a software company and make the standards conversion middleware to enable interoperability. This way we can have as many standards as wanted. It’s only software, which is easy and it comes with a perpetual license and nominal annual maintenance fee. Never mind interoperability – I am looking for investors in my idea.
You might also like...
Designing IP Broadcast Systems - The Book
Designing IP Broadcast Systems is another massive body of research driven work - with over 27,000 words in 18 articles, in a free 84 page eBook. It provides extensive insight into the technology and engineering methodology required to create practical IP based broadcast…
Demands On Production With HDR & WCG
The adoption of HDR requires adjustments in workflow that place different requirements on both people and technology, especially when multiple formats are required simultaneously.
If It Ain’t Broke Still Fix It: Part 2 - Security
The old broadcasting adage: ‘if it ain’t broke don’t fix it’ is no longer relevant and potentially highly dangerous, especially when we consider the security implications of not updating software and operating systems.
Standards: Part 21 - The MPEG, AES & Other Containers
Here we discuss how raw essence data needs to be serialized so it can be stored in media container files. We also describe the various media container file formats and their evolution.
NDI For Broadcast: Part 3 – Bridging The Gap
This third and for now, final part of our mini-series exploring NDI and its place in broadcast infrastructure moves on to a trio of tools released with NDI 5.0 which are all aimed at facilitating remote and collaborative workflows; NDI Audio,…