Broadcasting exhibitions tend to forecast on the latest and greatest technologies, but at least at IBC there is some sober reality lurking around the corridors and indeed evident in a few of the conference sessions. The two are sometimes linked in that emerging services and platforms create problems and issues that require actions from regulators that tend not to make the headlines.
This is the case with TV Anywhere, connected TV, smart TV, call it what you like, and in particular some of the associated changes in video delivery architectures. There is a trend from away the traditional bespoke broadcast delivery models towards generic IT-based approaches derived from the world of corporate data centres. But this is where the problems arise, for video and broadcast production, contribution and distribution involve components and systems not found in the IT world, which therefore require dedicated bespoke work from systems integrators to put together.
The European Broadcast Union was one of the first industry bodies to identify the serious lack of standard interfaces between components and systems, with the result that system integrators have to devote significant resources to the development of custom adapters to integrate components from different vendors. This also creates scalability and maintenance problems since these bespoke interfaces require further work as a system grows or is upgraded.
As a result, the EBU set up its P/NP group to develop a framework for interoperability of media services, with one key objective being to avoid broadcasters and TV operators facing the kind of lock in to one or two large dominant vendors that they have been subject to in the past, and that has afflicted the world of IT. Fortunately, the IT world has also evolved some models for interoperability between services and components at the high level necessary for them to work, notably with the Services Oriented Architecture (SOA), which is sometimes regarded as the forerunner and enabler of cloud computing. As it happens, cloud computing itself has become one of the hot topics in broadcasting as well as IT, but the EBU thinks that the industry should learn to walk before it can run and establish a sound basis for development of IT-based services in the emerging multiplatform smart TV world where end devices are all connected by IP, sometimes over the Internet.
Naturally, the EBU did not want to repeat work already done and so decided to adopt a model for SOA first developed almost a decade ago by the IT industry standards body Oasis as the basis for its planned framework. Subsequently, the EBU then found that the Media Workflow Association (AMWA), which focuses on file-based workflows to benefit content creators including film, television, advertising, Internet and post-production professionals, was working along similar lines. The two bodies then joined forces to develop the Framework for Interoperability of Media Services (FIMS), which was announced at NAB 2011 in Las Vegas, but without details. Now the EBU and AMWA are ready to unveil FIMS 1.0, which will be demonstrated at the EBU Village near the IBC conference centre during the exhibition. The demonstration will show typical media services including capture, transfer and transcoding, with exchange of media files wrapped in the OP1a MXF (Material Exchange Format) versioning format.
It will be seen then that FIMS uses standard tools and protocols, but the point about the Oasis SOA reference model is that it is agnostic about such matters. This is both its strength and weakness. The strength is that by avoiding dependence on specific interfaces or protocols with processes being loosely coupled, it is easier to introduce new services and change components. But the downside is that effort is required to shape it for a particular applications sector such as broadcasting and ensure that it really does deliver the desired interoperability, flexibility and reduced costs of deployment and maintenance. This is why it has taken the EBU and AMWA about three years to come up with the first version of FIMS, which specifically addresses five tasks for broadcasting: strategy for future TV production systems; handling of file formats; handling of files and streams in IT-based networks; business process management; and service-based system integration.
One important objective was to ensure that FIMS supported existing processes to enable migration to new IT- and-cloud based platforms as smoothly as possible. The core of FIMS is the Media Orchestration System, which connects existing applications for functions such as loudness control or media capture via adapters. But the idea is that following publication of the FIMS specification, future services and applications will be "FIMS ready" and can be attached to the Orchestration System without need for adapters. A key design goal, inherited from the Oasis SOA, is reuse, in that components providing generic functions can be exploited by multiple services by plugging into the Orchestration System providing they support the FIMS interfaces.
FIMS in effect is a joint effort between manufacturers and broadcasters, and so reflects the overlapping but distinct requirements of both camps. Manufacturers wanted to reduce the costs and risks associated with service and product integration. Broadcasters, operators and content distributors on the other hand are most interested in speed of deployment, although with cost and risk also being factors. The adoption of standard interfaces at the business level, which SOA promotes, should allow all those goals to be achieved. Delegates at IBC this year will get the chance to assess whether this is the case.