» Printable version

News

A Bottom-up Approach To MAM

TVB Europe - July 2009

By Nigel Booth, Executive VP, Sales and Marketing, IPV

As an industry we have been talking about asset management for a long time now: probably two decades. Yet there are still relatively few implementations of a real asset management application.

One of the reasons is that sales pitches always seem to emphasise how products enable you to take an enterprise view of your content. That may be true, but actually is not terribly helpful. Managing content right across an enterprise is a major challenge, in developing workflows that are appropriate for everyone, and in taking on the huge amounts of data involved.

At IPV we have taken a rather different approach. The broadcasters we have spoken to tell us that their applications are at the departmental level, maybe even at the individual programme level. Often they rarely need to share content around the enterprise, but they do have real issues with managing material in, for example, live sports coverage.

Take a broadcaster that has the rights to a major sports franchise. At busy times there will be a number of matches taking place simultaneously, each needing their own highlights packages, plus different edits for an overall discussion programme. All the action will also need to be logged so that it can be found quickly from the archive. If a player does something important or unusual today, you need to know if they have done it before, and get the pictures into the edit quickly.

Multiple feeds are coming into the ingest server, and a large number of users — editors, producers, loggers, archivists — need to have immediate and simultaneous access. That is a challenge, which needs a new approach to tackle effectively and cost-efficiently.

The key is to provide a tight integration between the online video server and full resolution content, a browse resolution proxy system, and the metadata that is used to route the content and to enable it to be found later. In other words, an asset management system, but one that is tailored to a specific task, not necessarily trying to be all things to all parts of an enterprise.

In the case of the sports example, the architecture is likely to involve an ingest server which is dedicated to accepting the incoming feeds from however many matches are being played, and writing that content onto a SAN for security and for access by other high resolution systems including playout. Tightly coupled to the ingest server must be the browse resolution server. This is, of course, the heritage of IPV, and we believe that our SpectreView system is still the best application in the field.

There are a number of reasons why you need a sophisticated browse system in this application. First, it has to be fast, so that the content as it is being ingested becomes available on the network virtually immediately: in our solution it is available on desktops within just a few seconds of the ingest server starting to record.

As well as being fast, though, it has to be flexible. If you are working as an online editor you are used to scrolling forwards and back through content, looking for the shots you want.Why would you accept lesser facilities on a proxy editor? The format has to be robust enough to hold up however you move through the content, which is a difficult proposition for streamed video.

The matches have started, the servers are recording, and content is now available on desktop computers. The next step is to marry the images and the metadata. Many broadcasters use specialist sports logging companies to provide moment-by-moment analysis of the action: metadata of the sport.

What the asset management system must do is accept this logging data and automatically link it to the video. If the logging service can provide an in and out timecode along with its comments, that is ideal. If there is only one timecode the system should set a pre-defined in and out point around it. Otherwise the broadcaster’s logging staff cannot quickly scroll through the desktop content to find the pictures that match the data. They may also need to add other, broadcast-specific data to the file, perhaps when a commentator says something particularly important or useful.

So it is likely that there will be more than one person logging metadata for each game. All this has to be aggregated into the database, in a standardised form so that it is easy to retrieve what you need.

No craft editor


At the same time, users of the content will be starting to work. Editors will be building the various highlights packages, usually under immense time pressure: it is now accepted practice to have a summary of the play the moment the whistle blows.

Because the content is already identified with relevant metadata — based on the specialist logging — each editor can quickly identify and transfer the required content to the editing bins. Access to the archive is also provided, using the same metadata, so clips from previous games can be used as easily as current footage.

Desktop tools can now do much more than simple cuts-only editing, so at least some production values can be introduced. A conform engine will render the finished edit in realtime on the server, so it can be played to air the moment the final cut is made. The desktop editing and conforming solution we have developed is certainly not designed to replace a craft editor, but it does open up the potential for high production values in a way that is simple and quick.

There will be some jobs that do need the refinement of a true craft editor, and the production network may also feature a product like Final Cut Pro. In a typical sports application, even when something goes to a craft editor the time pressure does not go away, so the handover must be fast and precise.

The solution is to pass the EDL direct from desktopeditor to craft editor, and at the same time call down from the online server only the clips that are actually required, with suitable handles to allow the edits to be trimmed. This is rather like imposing a partial restore, this time from the SAN to the local bin on the editor, and again this requires careful integration between the database and the hardware.

Whether the edit is completed on the desktop or in a craft suite, it has to be checked for accuracy, conformance and quality, then handed on to the playout server. Again, this has to effectively happen instantly, so it is vital that there is tight integration and precision with the browse edit.

This is precisely the requirement specification and architecture IPV has already delivered to a major broadcaster covering prestigious live sport, based on our Curator product. Because it is readily scalable, it can be built out like blocks, with a single application leading to a department-wide implementation — and maybe even one day that enterprise-wide asset management, starting from the bottom up.
For a direct link to this article use the following link:
  http://www.ipv.com/news.html?217