<img height="1" width="1" src="https://www.facebook.com/tr?id=414634002484912&amp;ev=PageView &amp;noscript=1">
Donate
SMPTE stands with our friends, colleagues, and family in Ukraine, and with all people of Ukraine
Donate

How Lessons From IT Can Drive Innovations in Media Technology

August 17, 2022

Join/ Renew My Membership

In the August issue of the SMPTE Motion Imaging Journal, SMPTE Fellow and media workflow expert Brad Gilmer explores “Advancements in Information Technology Applied to Professional Media.” He notes that media companies are under ever-increasing pressure to produce, deliver and monetize content more efficiently for devices and platforms that are evolving at a dizzying pace. In particular, viewers demand experiences that run the gamut from traditional long-form content with minimal interaction to content that is dynamic and interactive. To meet these challenges, Gilmer proposes a blending of the best practices from IT and computer science with a deep understanding of professional media. IT best practices have long been focused on delivering agility, flexibility, scalability, and composability (the ability to select and assemble system components in various combinations to satisfy user requirements). And, applied to media, they can help create dynamic and flexible systems that quickly adapt to shifting workflows and a rapidly changing business environment.

A key concept in IT is that of naming Resources and Immutable Objects. Everything, including different versions of content, production control rooms, studio cameras, playback servers, technical crew, and virtualized transcoders in the cloud, is considered a resource that can be scheduled and managed. But if you’re going to harness these resources, each must be uniquely identifiable and accessible without reference to its form, location, and function. An immutable object is a resource which cannot be altered in any way after it is created. Any change, no matter how slight, results in a change to the unique ID of that resource. 

A generic Content Application Programming Interface, or Content API, is a unique resource ID that includes information about the device, domain, content, and stream of the resource, which can be used to find, synchronize, and process the components. The Content API serves as the main interface between content creators and a persistent content store in a new kind of media facility, and can be used to provide content in response to well-formed queries at the interface. If the facility has this kind of common framework for uniquely naming resources, enforces the concept of immutable objects, and prevents end-runs around the system, then it can unlock tremendous power in its media systems. It can also ensure business continuation, making it easy to balance the load across multiple servers with similar capabilities, allow it to take specific servers offline for maintenance, and much more.

Another key concept in IT that can apply to media is Idempotency, the idea that if you apply the same operation, you’ll get the same result every time. For instance, separate “stop” and “play” buttons would be idempotic, whereas a single push-button toggling between “play” and “stop” would not. The principle of idempotency greatly simplifies control in IT systems and is one key to enabling scaling.

Most media control and automation systems are designed to know the State of Devices in their domain, but this requires the storing and updating of a great deal of information. If you increase the size of any system, however, the amount of state information in the system grows exponentially. Many IT systems, however, use a publish/subscribe model where you can subscribe to notifications about the device, which publishes its status on a regular basis or when it changes, notifying all subscribers. This data-centric control design is invaluable in troubleshooting since it’s possible to “playback” the database to go back in time, simulating the states of all subscribed devices. It also improves visibility, reliability and particularly scalability, since it’s not necessary to store device states between requests, allowing the server component to quickly free resources and simplify implementation. 

Another IT concept is Eventual Consistency, the idea that it’s better to focus on making sure databases are consistent over time rather than that they’re consistent at all times. This is important because as media systems become very large and the number of transactions grow to thousands per second, trying to keep everything in perfect synchronization can cause performance to suffer until the system stops functioning. Eventual consistency allows the applications to scale tremendously with no impact on integrity. The critical leap in thinking is to look at the user requirements and understand if absolute synchronization at all times is really necessary. It turns out that in many cases, it is not. 

A Microservice is a network resource that does one thing well. The output of a few to hundreds of microservices may integrated into a unified view and presented on your web browser. A typical monolithic application, on the other hand, may provide hundreds of functions all rolled into one computer program. The difference between the two systems is imperceptible to the end-user, but the architectures are quite different. In the microservice approach, requests are quickly parsed through a backend which delivers the requests to the appropriate microservice. Each microservice is responsible for its own data and stands on its own, allowing it to be maintained or changed without taking down the entire application. Their use has become a best practice in IT as a way to control complexity that can lead to difficulty in maintenance, modification, and testing which leads to instability and unpredictability. Microservices enable scalability, fault tolerance, ease of upgrades, simplicity in documentation, and much more.

Other concepts which can transfer from IT to Media include:

  • Single Source of Truth, in which there is one authoritative source for every piece of data without duplication. 
  • Automation in testing and deployment of new code as part of the normal software development workflow. In this trend, infrastructure as code (IaC) allows facility designers to create, test, and deploy new facility configurations, all under automation and version control. They can also quickly change the facility’s “wiring” or deploy infrastructure changes during less critical periods, with the ability to revert back to the previous configuration at the push of a button.
  • Security issues, on which the European Broadcasting Union (EBU) has done much work including testing media applications, providing security recommendations for equipment acceptance, and proposing a framework of alerting people to the vulnerabilities in the industry.
  • Self-Documenting APIs are clearly a priority in Media. They should be well-written and self-describing, do one thing well, be simple to understand and use, and contain information and documentation that help developers create successful implementations.

Gilmer makes it clear that media consumers are now demanding the same agility, flexibility, scalability, and composability that have helped the IT industry prosper. He suggests that the way forward should carefully consider how we can adopt the bedrock principles that have enabled modern IT and computing, as we build the next generation of professional media facilities.

For more details about following the best practices and patterns from the IT world, read the complete article in this month’s SMPTE Motion Imaging Journal.

 

Keywords:

#Brad Gilmer #composable # dynamic media systems #immutability #IP systems #IT thinking #user requirements #workflow #content API #Idempotency #device state #eventual consistency #microserve #single source of truth #automation #security #self-documenting API

SMPTE Content

Related Posts