For some time now, we have been moving away from video-centric technologies and moving toward IT-based facilities. But designing, building and maintaining enterprise-level production systems is still a challenge for most broadcasters.
The market is rapidly changing, with growing competition across a variety of delivery platforms including traditional broadcasting, mobile and the Internet. In this context, the promise of a more efficient framework for creating, processing, managing and leveraging digital assets would be welcome.
Broadcasters have been, to a large extent, successful in moving to IT-based platforms. Almost every broadcast facility has a professional IT router in addition to its classic A/V router, and software systems now form the backbone of what we do. When I talk to many of the larger broadcasters, they have also been successful in integrating different software products into a coherent system. But along the way, I have also found that broadcasters have needed to resolve a number of interoperability issues to get things working. Many times, these interoperability issues are solved with glue software (special applications that facilitate communications between systems) and with transcoders. Interestingly, these transcoders are not only flipping content from one video format to another, but they are also performing software glue functions to get metadata associated with the video streams converted so that it can be understood by the follow-on applications.
In the early days of integration between traditional A/V systems and the IT world, broadcasters built monolithic, purpose-built facilities, just as they always had. One set of equipment and software was dedicated to one TV channel. As capabilities and computing power improved, broadcasters moved to multiple channels originating from a single facility. But they still built stovepipe facilities, where workflow was closely tied to equipment configuration.
Somewhere around this time, the industry was hit with the proliferation of potential A/V targets for broadcast media, and the fun began. These new platforms required their A/V feed in a particular format, with associated metadata. Additionally, there were real questions as to whether the revenue generated from these platforms would support another monolithic playout facility just for them. In fact, it was certain that many of these opportunities would not generate revenue to offset the costs of feeding them content, but broadcasters had no choice. So, as usual, broadcasters and broadcast manufacturers, being an innovative bunch, figured out ways to make it all happen. But the solutions were not always elegant.
The real problem, however, began as these brittle custom-built stovepipe systems were constantly modified to rapidly adapt to these transient, ever-changing opportunities. As services came and went, and morphed into different services, the requirements for feeding these new outlets kept changing. Monolithic systems do well at meeting a set of requirements that are stable, especially if you give the engineers some time to work out the bugs. But they do not do well when the requirements and the outputs keep changing. Another approach was needed.
A services-based approach
To meet these changing requirements, broadcasters borrowed a concept from the IT world — the idea of services. A simple example might help to explain this concept.
Ingest is a common process that is used in news, post, broadcast and Internet publishing. In this example, ingest is defined as the process of taking a tape and transferring the audio/video into a file on a server. During this process, a small .XML file is also created, which contains slate data. In a typical facility, a broadcaster might have many different ingest clients. These clients all perform the same basic function, but they may have different capabilities. Some may be closely tied with other follow-on systems; some may be stand-alone processes. But in each case, they all offer the basic functionality of ingest.
There are two ways to interface to this ingest application. The first, more traditional, way would be to write code that specifically interfaces this ingest software to other systems on the network using an application programming interface (API) provided by the ingest manufacturer. One of the goals of this integration might be to pass the file name of the finished file to other programs when an ingest is done.
Once installed, the system may meet our user requirements, but it is tightly integrated with other processes. Changing or upgrading the ingest client will result in additional work to ensure that all of the interfaces are upgraded as well. Furthermore, perhaps this ingest client would work perfectly well for an Internet-based network, but because it is hard-coded, additional interfacing is required to make the ingest output available for a new system.
Another way to interface to this ingest application would be to present the ingest function as a service. Conceptually, this is simple. An ingest service exists out on the network. A user can employ this service to convert a tape to an A/V file with .XML slate information. Think of the ingest service as a building block. If you connect an ingest service to a move service, to a publish service, imagine how you could build a simple facility that ingests content, moves it to the appropriate playout facility and then plays out the content at the appropriate time. Admittedly, this is a 50,000ft view, but the example illustrates a few key points about service-based production.
First, each of these services is a stand-alone block. Second, the blocks are reusable; you can use the move service for all sorts of things, not just moving content from ingest to a playout server. You could just as well use the move service to move the content out of a post house to a broadcast facility in a different city. Third, these blocks can be put together in different ways to build facilities that can adapt to changes in your business.
Going back to the current state of the industry, almost every large media company has deployed services within its facility because this approach addresses many of the problems broadcasters encountered when initially building software-based media systems. And while there have been problems, these systems, comprised of a number of independent services, are delivering content to viewers every day. But the problem is that each one of these media companies has embarked on its own development process. Vendors participating in these projects have frequently needed to develop service interfaces that work inside User A's facility, but then develop another set of service interfaces that work inside User B's facility — and so on. So while services are successfully deployed, there is a lack of standardized interfaces, a lot of wasted effort in bespoke interface development and a dearth of reusable services.
Framework for interoperable media services
To address this issue, the Advanced Media Workflow Association (AMWA) and the European Broadcast Union (EBU) have created the Framework for Interoperable Media Services (FIMS) Task Force.
Here are the main objectives of the FIMS Task Force:
- Establish an overall framework for integration of reusable components for multimedia content production or, in other words, develop a common service definition format.
- Test the framework on three interfaces. Three basic production services will be used: interactive capture, transform media and transfer media.
- Once a common format has been defined, FIMS intends to explore the possibility of identifying services for the entirety or a subset of the professional media industry.
To be successful, we should achieve more than just creating reusable media services. The expected benefits are the interoperability of systems and components, flexibility in the design, configuration and upgrade of production infrastructures, agility in workflows, and acquisition and operational cost control for both user and solution providers.
Earlier this year, the FIMS Task Force sent out a Request for Technology, with the intent of achieving the goals laid out above. Figure 1 illustrates the domain of interest for the FIMS work. At this point, AmberFin, BBC, Cinegy, IBM and Sony have responded. Several other companies have expressed interest as well, and the effort is open to users and manufacturers who are interested in the topic. The FIMS team is now working to create a first draft of what is hoped to be the first standard written to tackle interoperability of services in the media industry.
The project is a big one, and there is no guarantee that we will be successful. But the timing appears to be right. People are willing to tackle the project, and trade bodies are willing to provide a platform for the work. I hope that I will be able to report on progress in this area early next year. For further information, visit www.wiki.amwa.tv/ebu.
Brad Gilmer is president of Gilmer & Associates and executive director of the Advanced Media Workflow Association.
Send questions and comments to: brad.gilmer@penton.com
