The proliferation of software within broadcast environments is having a major influence in television. Innovative and new features are being delivered with breath taking speed enabling program makers to reach ever higher levels of creativity. But in this new agile software world, what is a standard?
Broadcast television has its roots in hardware. Up to recently, the massive real-time speeds needed by live television demanded cutting edge hardware only found in bespoke systems. However, advances in other industries, such as high-performance computing, have demonstrated broadcasters no longer have exclusivity on speed and performance.
A broadcast infrastructure is held together with standards and specifications from organizations such as SMPTE, AES and ITU. Video, audio, and metadata is easily distributed and if I connect a camera output complying to SMPTE-292M to a monitor with the same specification, then I will see pictures.
NMOS have made massive gains in driving forward their ideas to make professional audio and video automatically discoverable and interoperable. The key difference with their solution is that the software specifications are freely available on Github, a document repository where anybody can download the specifications and one that actively facilitates change. This is more akin to how the IETF manages the RFCs (Request for Comments) that make up the internet suite of protocols. Change is normal.
We have seen from the adoption of IP that open source specifications operate effectively and can gain international adoption. RFCs were a result of engineers sharing ideas, documenting them, and eventually making them into working specifications.
One of the interesting aspects of a standard is that it gains a certain gravitas, almost to the point where it becomes “set in stone”. This isn’t surprising as hardware development cycles can take many months or even years to complete to a level where products can be shipped, especially as some of the solutions require highly specialized silicon design to cope with the speeds involved.
However, software development is much faster, especially with the largescale adoption of agile development practices where entire new features can be deployed every few weeks, or even sooner. Some organizations promote daily software releases as it keeps the effects of bugs to a minimum. This is a whole new way of working and requires a new way of thinking.
Although software developers must have an appreciation of the future, agile methods demand agile solutions, so they do not need to think years ahead, unlike their hardware counterparts. Developing hardware solutions can be incredibly expensive due to the upfront design and prototyping costs. Consequently, hardware design engineers try to future-proof as much as possible and build as many features as they economically can into a product. As opposed to software developers who build the precise number of features needed for that time. With such short development cycles and scalable hardware, future proofing is almost irrelevant.
This leads to two different types of standard; the hardware version that tries to include every possible feature for now and for the future, and the software version that provides just enough features for today.
In my view, both of these approaches are correct, and both deliver solutions for their specific use cases. As broadcasters move more to software and IP then they will need to think more in agile terms.