By Jean-Pierre Evain (EBU), Loic Barbou (Triskel), Richard Cartwright (Quantel) and Abbe Wiesenthal (Turner)
IBC2015 offers the perfect venue to update the broadcasting community on FIMS (Framework for Interoperable Media Services) initiatives. FIMS is a joint project of the Advanced Media Workflow Association (AMWA) and the European Broadcasting Union (EBU) with a membership of more than 100 companies.
A lot has taken place since the project first won the IBC Judges’ prize in 2012. Not only have we significantly enriched our technical specifications, but more importantly, vendors now recognise the value of the proposition and are offering FIMS-compliant products.
Why FIMS? The current media landscape mandates that companies address a constantly accelerating rate of change of technologies for media creation and consumption, with increasing consumer expectations and a proliferation of delivery platforms and formats. Business models need to be easily adaptable to sustain the change and support content creativity as well as technical innovation, such as the shift from file-based to IP stream-based workflows.
Streamlined Media Supply Chains must be put in place for generating and managing large quantities of video and audio in different formats to suit the requirements of different regulatory environments, regional and cultural audiences and distribution platforms. In the past, as these systems evolved, media flows were tightly coupled to the technologies, resistant to the changing business environment. This must be simplified to achieve modern efficiency, hence the creation
of FIMS.
FIMS defines open services that are loosely coupled, enabling multi-vendor services to be integrated and creating ‘best-in-class’ media systems. The bottom line is that implementing FIMS’ framework provides agility, interoperability, interchangeability and reusability of media related services. In order to achieve this, great attention is devoted to the decomposition of systems into business processing units that are highly re-usable if exposed as services through common interfaces.
Two services that expose the same interface can be considered interchangeable and equivalently, two services that implement the same business function must expose the same interface. This greatly reduces the number of interfaces that must be implemented to connect different components on a composite system. Another important characteristic of this Service-Oriented Architecture is to keep business process logic separate from service implementation. FIMS interfaces can abstract vendor interfaces but vendors can also natively implement FIMS.
Synchronously or asynchronously
The FIMS specification has been developed for media and is aware of long-running processes. FIMS supports processes to run synchronously or asynchronously. Associated job management functionalities include control for prioritisation, status monitoring and fault management.
A job request contains all the parameters needed for its execution, optionally a description of the media content on which the command operates, and the execution parameters grouped into profiles. It also provides an extension mechanism for the inclusion of vendor/user specific parameters where needed. The Orchestration System calls Media Services via FIMS interfaces over the IT network using a web services protocol such as SOAP, or accessing RESTful HTTP resources, and combines them in agile workflows.
FIMS supports the management of partial content and will soon support “growing” content in the context of live IP production. Beyond the service-based infrastructure, FIMS is also a strong data model for flawless management of technical and descriptive information in the workflow. The FIMS data model is based on EBUCore (see: https://tech.ebu.ch/MetadataEbuCore).
Interfaces for basic
media services
FIMS follows an established process. Under the leadership of Cognizant, the FIMS Business Board, exclusively composed of users, defines the requirements and priorities and charters new FIMS Services. The FIMS Technical Board, chaired by Bloomberg/Triskel, defines and realises the specifications. The continuity and coherence in the development of successive specification is ensured by the FIMS Architecture Council led
by Quantel.
FIMS 1.2 already provides the definition of the following interfaces for basic media services:
• Transfer service: to copy or, optionally, move one or more files to another location.Five different transfer protocols are permitted:HTTP, HTTPS, FTP, SFTP and FILE.
• Transform service: to alter essence and container formats. The main intended usage is transcoding or transwrapping of media files but it can be easily extended to provide other types of transformations, like cropping, filtering or colour grading.
• Capture service: to convert stream-based realtime input such as HD-SDI or RTP to one or more files. It is based on the transform service adding provision for realtime input handling, including manual start/stop or bound-to-time events.
• Repository service: provides the basic CRUD (create, read, update, delete) functionalities needed to manage persistent assets and their related metadata. The interface also provides all functionalities that a workflow engine needs to query and retrieve media assets from storage, including job monitoring and repository capabilities.
• Quality analysis (QA): The QA interface provides the basic mechanisms to identify the capabilities of a quality control tool, control commands and also a common report format. This interface has been developed in strong cooperation with EBU QC (Quality Control). FIMS QA is the first interface that uses resources other than content, i.e. test templates and reports.
FIMS QA is also the first FIMS service providing extended service capability discovery following the recommendations of SMPTE 2071.
• Partial content: Content parts defining long varying timelines can now be combined for uses such as non-linear editing. Mechanisms are now provided to manage the genealogy of content (where is content or part of content coming from, parent/child relationships).
FIMS 1.3 is already announced with more:
• Automatic Metadata Extraction: The AME interface allows discovering capabilities and drives automatic metadata extraction tools.
• Semantic metadata: The intention is to extend the existing FIMS data model into a semantic model to benefit from scalability and extensibility of semantic web to facilitate mapping and customisation.
• Extended discovery of service capabilities: The work on service capability discovery started for quality analysis will be extended to other services.
• IMF, UK-DPP AS-11, etc.: This is also on FIMS’ agenda and work is already in progress.
Why not join now?
With FIMS, there is now an interoperable solution for interfacing orchestration engines and services. The main short-term advantages of FIMS for users are:
• Clean, consistent and vendor-independent design of component interfaces.
• Ability for vendors to leverage the flexible and generic FIMS interface to expose their products’ APIs as a standardised and robust interface that seamlessly integrates with other compliant products for media exchange.
• Minimisation of integration costs and system complexity for media organisations through standardising operations for storing media assets in a vendor independent way.
More substantial advantages are expected in the mid-term with a growing market adoption of FIMS. Standardised interfaces provide ease of maintenance, scalability and repurposing of systems with the freedom to always choose best of breed products.
Equipment vendors, MAM solution providers and integrators are now acknowledging the value of FIMS. Learn more on the FIMS channel (https://www.youtube.com/channel/UChWrxCykI9mznxo3iYTonyg) with presentations from FIMS implementers and promoters. Video guidelines are also available.
The official FIMS website provides a wealth of information at http://fims.tv. There is also a LinkedIn FIMS SOA User group periodically communicating recent news.
