Broadcast Engineering | Testing FIMS .0

Published: Feb 23, 2013, Media Coverage, By Ian Hamilton, Signiant Chief Technology Officer

The rapid pace of change in the media industry demands that leading media organizations implement efficient and agile digital media processing capabilities to control costs and capitalize quickly on new business opportunities. However, achieving the full promise of file-based media workflows and the efficiencies they bring requires seamless interaction among products from different vendors. Therein lies the challenge: Getting disparate products to interoperate is like getting a group of individuals each speaking a different language to understand each other. The effort requires standards for more than just the words or the dialogue i.e. the file formats. Seamless interaction also requires standardizing the way the dialogues are handled i.e. the approaches to coordinating and connecting the components of media processing systems.

Most modern businesses today leverage service-oriented architectures (SOAs) to assemble agile business systems. Indeed, SOAs offer tremendous advantages to processing media for playout and distribution. A key element of SOA involves exposing system components as shared network-based services. Connections with services can then be created and reconfigured quickly to respond to changing requirements and demand.

The Framework for Interoperable Media Services (FIMS) was initiated as a joint project between the Advanced Media Workflow Association (AMWA) and the European Broadcasting Union (EBU) to create a common framework for applying SOA principles to processing media. FIMS standardizes service interface definitions for implementing media-related operations in a SOA. As one example of how it can be used, a system that ingests and prepares content for playout and nonlinear delivery can leverage FIMS to interact flexibly with media capture, transfer and transform products from multiple vendors. Using FIMS, system components can easily be added, updated and removed in response to changing business requirements and demand.

The problem Although workflows are commonplace for moving, processing and storing media using software-centric systems deployed on commodity IT infrastructure, many software-based media processing systems suffer from problems endemic to older hardware and physical media-centric film and video processing systems. Whenever unique media processing requirements must be addressed and let's face it, what broadcaster does not have a unique requirement of some sort there's an expensive custom software integration project needed to delivered bespoke hardwired media processing silos.

Worse yet, many software-based systems use watch folders to hand off media between components of the system. While watch systems can allow multivendor interoperability and loose coupling, they create a whole new set of quality, reliability and management problems.

The approach FIMS focuses on the abstract service layer that connects applications and orchestration systems with services that perform operations on media like capture, transform and transfer. (See Figure 1.) FIMS addresses media specific requirements associated with the resource-intensive nature of processing and storing media.

For example, FIMS accommodates long-running processes by incorporating an asynchronous calling pattern and resource prioritization through queuing. The FIMS 1.0 specification defines services interfaces for capturing, transforming and transferring media, with ongoing development efforts under way to define additional services. With FIMS, a workflow that receives media, transcodes it into the required formats and then transfers the result for linear playout and nonlinear distribution can easily be automated through standards-based service orchestration.

Figure 1. FIMS Reference Model

To those unfamiliar with SOA and Web services, the breadth of products and technologies marketed by big IT vendors can be intimidating and overshadow the underlying principles. The FIMS 1.0 specification avoids much of this complexity by defining a resource model as a central component of interaction between service providers and consumers. The resource model approach places more emphasis on what is being communicated between the service consumer and provider than on how it is being communicated. This allows a neutral position on Web services technical debates such as those concerning SOAP versus Representation State Transfer (REST).

The main resources in the FIMS 1.0 model are Services, Jobs and Media Objects. Jobs are processed by Services to perform operations on Media Objects. In the context of the resource model, the Media Objects are formally called Business Media Objects. This qualification is made because these objects only contain the metadata relevant to the business operation being performed along with information about how to access actual media content.

FIMS 1.0 also makes a clear distinction between Media Objects on the message bus and the media bus. The term bus is borrowed from computer architecture where a bus is asubsystem that transfers data between components of a system. The message bus is used to communicate information about media, including media processing instructions. The media bus is used to store, access and move master, mezzanine and finished media products. This model is analogous to the management of physical products where business systems track raw materials, components and inventory for associated real-world objects that are stored and transported using warehouse, ships, planes and trucks.

FIMS Test Harness Project A practical approach to standardization requires more than object models and interface definitions to gain serious traction. Consequently, the FIMS Technical Board recognized the need for a tool to help FIMS implementers validate their implementations.

LINK:	http://www.signiant.com/news/media-coverage/broadcast-engineering-test...
	See more stories from signiant

Most recent headlines