COMMUNITY

What is Metadata? What can it do for me?
How do these benefits accrue?
Target Users of the System
How is Metadata transported in a file-based Infrastructure?
Literature Request

What is Metadata? What can it do for me?

Metadata is information which relates to the "essence" that is video, audio, subtitles, signing. One definition is "bits about bits".

Metadata can be split into four main categories:

• Technical: Aspect Ratio, MPEG format, Colorimetry.
• Legal: Copyright ownership, cast names.
• Commercial: Cost of production of clip, number of plays allowed.
• Production: Script, Story Board, Versions.

So what is new, much (even most) of this information is already stored.

True, the problem is that this data was not directly referenced to the content as this was invariably a video tape (or film can) with its label falling off on a dusty shelf somewhere in a basement archive.

To commercially exploit this archived content, it is necessary to consult multiple and disparate databases.

Studio quality video compression techniques have reduced the data rate to a point where it is economically possible to store content as files. The use of IT servers and networks provides for fast random access to stored content, provided that an accurate cataloguing system exists - often referred to as MAM (Media Asset Management).

SMPTE created the definition "Content = Essence + metadata". The equation we are trying to create is "Asset = exploitable content", the first requirement is to be able to find it!

These advances are taking place in an environment where the key business driver is to reduce the cost of programme production at a time when the number of channels to the home is increasing and the advertising spend is approximately flat.

How do these benefits accrue?

Content Creation

• Improved workflow, improved use of scarce resource
• Ensuring that information which is created before and during shooting is not discarded.
• Cataloguing what is currently thrown away - Shooting ratios for high quality content are frequently greater than 20:1.
• Re-use of existing clips, instead of re-shooting content - can only happen if the content (and its conditions of use) are easily found.
• Legal / Copyright ownership and production time / cost can be logged against each clip.

Content Re-versioning

• Simple re-versioning of existing content (censorship.) - processing only required at editing points.
• Storage of multiple versions as metadata + clips in order to rebuild new versions as required (only one video content is stored).
• Legal and Commercial information can be simply tracked and added to.

Content Re-purposing

• Passing forward of technical metadata to permit optimal transcoding to alternative bitrates / MPEG flavours i.e. VOD, DVD.
• Additional legal and commercial requirements can be added and tracked.

Content Sales

• B2B content sales today are normally limited to finished programmes, sales can be increased by improved access via browse copies and web access. Commercial & Legal information can be made available in parallel.
• Such a system should also allow the B2B sale of clips (rather than finished content) - this is new business model for content creators and the size of the market is unknown.

The opportunities described above could be exploited by any content creator or distributor who is prepared to risk designing his own system today. So what has held them back?

• Cost of implementing a one-off proprietary system
• The desire to use "open standards" to prevent supplier lock-in
• The requirement that they can still play back the files in 50 years time
• The desire to sell content (and metadata) to other broadcasters for incorporation in their own programmes demands a standardised solution.

To understand these user requirements and to propose solutions, the EBU / SMPTE Task Force for Harmonized Standards for the Exchange of Programme Material as Bitstreams was set up. In August 1998, it produced its final report and the SMPTE agreed to produce the necessary standards to support this vision.

This has taken considerably longer than was originally believed, in large part due to the lack of understanding the majority of broadcast engineers had in the IT world and vice-versa.

The required standards are now in place from SMPTE including MXF and the AAF Association for Authoring.

Target Users of the System

As content is still King, the efficiency of the "creatives" is the limiting factor determining (high value) programme output. The system is therefore designed for "creatives" rather than for engineers.

For this reason the fundamental element of both content and metadata is the clip. That is a sequence of images and sound that are continuously shot.

Each clip is uniquely labelled using a UMID (Unique Material Identifier) and all information is logged against this identifier.

How is Metadata transported in a file-based Infrastructure?

Both MXF & AAF file structures have been defined to be flexible enough to hold any type and quantity of metadata whether technical, legal, commercial or production. However, having both essence and metadata together does not necessarily create the optimal workflow as, for example:

• It does not make sense to search a file containing 90% video content to find whether a specific clip contains images of, say, Sydney Harbour Bridge.
• Legal and commercial departments are very concerned about the internal security of their legal and commercial information - they demand control over their own databases and specifically database access.

For these reasons, different databases will exist containing references to the same clip via the UMID. More worryingly, some metadata elements may be contained in multiple databases. The management and update of the UMID and the rules governing this must be clearly defined if data integrity is to be maintained.

Finally any metadata that is placed in external databases must use a common data model, otherwise the relationship between the databases may not have a simple mapping. (The Ingest Station creates metadata in either or both MXF or as an XML file with a defined API - it is essential that the same data model is followed in both cases to ensure no ambiguities are created between these different representations.)