PrestoCentre Standards Register

The PrestoCentre Standards Register gathers information on standards for content and metadata used across all communities involved in audiovisual digital preservation.

EBUCore v1.5 Includes the New EBU Audio Model (ADM)

The new version of EBUCore can be downloaded as EBU Tech 3293 v1.5. Thanks to the efforts of the metadata experts in the EBUCore developer and user community, the new version of the EBU's metadata flagship includes several enrichments.

The most prominent update probably is the integration of the recently published EBU Audio Definition Model (ADM) (EBU Tech 3364). The ADM provides a complete set of technical and informative metadata to describe a file's audio content.

Graphical representation of the EBU ADM (click to enlarge)

It is designed not only to support current channel-based audio configurations such as 5.1 and 15.1, but also to be ready for future formats, by using ADM extensions. The ADM is shared with other standards organisations, such as the AES, AMWA/EBU FIMS, ISO/IEC MPEG, ITU, SMPTE and W3C.

All EBUCore additions are clearly documented in the new version. Special attention has been paid to simplifying the specification, by focussing it on examples of implementations. A 'Download Zone' chapter provides links to the related Schema, including semantic technology in the form of the updated EBUCore RDF/OWL ontology.

Source: EBU

Metadata and MXF

Most video professionals are now quite familiar with metadata. But, just to be sure everyone is on the same page, when we use the term metadata in this tutorial, we are referring to information (data) that typically refers to a program, commercial or other video/audio content. Examples of metadata include: the name of a program, the length of a segment or an ISCII code associated with a commercial.

Collectively, video, audio, subtitles, AFD and other things people consume as part of a program are known as essence. Just remember that essence refers to the stuff we are watching when we view a program. Importantly, essence includes data (subtitles, teletext, AFD and so on). If we want to talk about data that is part of the program, we talk about data essence. Data essence is not metadata; data essence is part of the program that is intended for “viewing” by the end consumer.

Technical vs. Descriptive
Metadata tends to be treated as a single topic. But, in our mind, there are several different ways to classify metadata. One way to look at metadata is whether it is technical or descriptive. Technical metadata is metadata that is required to identify and play back essence properly. Examples include: a Unique Media Identifier (UMID), information about compression used and raster size.

Descriptive metadata is typically the sort of information operators in professional media organizations care about — program title, show number, kill date, ISCII code and so on. Descriptive metadata might also include things like shot notes, scripts and music scores.

Some metadata falls into a grey area. How would you classify GPS location, zoom and focus setting, crank rate, or robotic camera position? Is this technical metadata or descriptive metadata? Generally speaking, technical metadata is directly related to the essence or essence coding and does not include these data types.

Another way to classify metadata is to think about how frequently the metadata is expected to change. We would expect some metadata to remain constant for the duration of the content being viewed. For example, we would not expect the title to change halfway through a program. In the United States, we might expect that the technical metadata regarding frame rate would remain at 59.97Hz for the duration of the program. As you can see from these examples, the frequency of metadata change is an orthogonal classification (meaning it is completely unrelated) to the metadata type (technical or descriptive). Not surprisingly, metadata that remains constant is called static metadata.

Other metadata, such as timecode, would be expected to increase monotonically (increase by a count of one, only) on every frame. Timecode and other metadata may, therefore, be placed on a timeline that increases predictably, and should never decrease (run backwards) or unexpectedly jump ahead. This type of metadata might be called timeline-related metadata.

Finally, metadata associated with shot logging, describing actors in scenes or associating a music score to a section of a program may appear fixed for a period of time, may be duplicated in several locations during a program or may even overlap with other similar types of metadata. This metadata can be referred to as event metadata.

There is one other important family of metadata, and that is perpetual metadata. As you can guess, this is metadata that should never change. Systems rely on the fact that these metadata items are immutable. If something is immutable, it means that it cannot be changed after it is created. Examples of this include a unique ID and the location where a program was filmed. Remember, systems will count on the immutability of certain metadata. If you violate the rules, all bets are off.

Why does all this matter? Because, in the end, media professionals build and operate systems, and these systems need to be properly designed to handle all of these different types of metadata.

Metadata and Essence
How do you tie timecode or program title to a specific copy of a movie? In the tape world, the question was irrelevant. The timecode was either stored in the VBI or in the ANC data, and the program title was printed on a label on the box or the tape itself.

But, things have changed in the file-based world. Associating metadata, especially technical metadata, to a particular program can be critical. Professional file formats must contain not only video and audio, but also the technical metadata necessary to play back the content. When it comes to descriptive metadata, the door was left open as to exactly what types of descriptive metadata were to be included in the file. This is both good and bad. One of the most critical linking mechanisms between metadata and essence is the UMID. The UMID is a unique identifier that is used to identify a particular piece of content.

UMIDs and the Contract
It is important to understand that there is an implicit contract between systems that create content labeled with a UMID and systems that later manipulate the content or rely on the UMID to retrieve the content. Here is the contract: A system will never break the connection between a particular piece of content and the UMID that was originally associated with that content.

If you create a new piece of content, give it a new UMID. Simple, right? But, here is a twist: What if you create a bit-for-bit exact copy of the file? The rule is that you duplicate everything, including the UMID. But, now you have two copies of the content with the same UMID. Is this right? The answer is yes. And, if you ask a media asset management system to retrieve a piece of content using a UMID, you cannot say for certain which copy you will get. The particular instance of a copy of content is not uniquely identified by a UMID. For other reasons, a MAM system may uniquely identify each copy of the same content, but the UMID should not be used to do this.

In a file-based world, metadata becomes key. Understanding how unique identifiers work and treating them correctly is vitally important. Fortunately, manufacturers hide most of this from end users, so you may not even be aware that UMIDs exist.

By Brad Gilmer, Broadcast Engineering

EBUCore: the Dublin Core for Media

EBUCore was first published in 2000. It was originally a set of definitions for audio archives, applied to the Dublin Core, which is itself a generic set of descriptive terminology that can be applied to any content. XML was then in its infancy but its use would grow dramatically, demanding more structured information to describe audiovisual content. Since then, other semantic languages have greatly influenced the way this information is modelled. EBUCore followed this evolution to become what it is today: the Dublin Core for media, a framework that can be used to describe just about any media content imaginable.

EBUCore is the fruit of well-defined requirements and an understanding of user and developer habits. User friendliness, flexibility, adaptability and scalability are more important than richness and comprehensiveness allied to impossible compliance rules. The richer the metadata, the higher the likelihood that implementers will reinvent their own. History is full of such examples. The golden rule for EBUCore was and remains "keep it simple and tailor it for media".

EBUCore covers 90% of users’ needs and its use is no longer restricted to audio or archives. Based on the simple and flexible EBU Class Conceptual Data Model (CCDM), EBUCore's ontology (categories and structure), which is expressed in RDF/OWL (Resource Description Framework/Web Ontology Language), can be used right through to the delivery of content to the end user. It responds to the need for more effective querying. It also paves the way for effective metadata enrichment using Linked Open Data (LOD).

EBUCore was designed to be a metadata specification for “users with different needs” and duly serves this goal. Delegates at the EBU’s Production Technology Seminar last January heard a wealth of evidence pointing to the key role that EBUCore is now playing. Several speakers explained how they have deliberately chosen and benefited from EBUCore.

The EBU-AMWA FIMS project, creating a vendor-neutral specification to interconnect production equipment, has adopted EBUCore. The FIMS 1.0 specification uses EBUCore as its core descriptive and technical metadata. FIMS is a vital project for the future of file-based production and feedback received from participants has influenced the most recent version of EBUCore. Early adopters of FIMS, such as Bloomberg, are using this metadata.

The UK’s Digital Production Partnership (DPP), which recently published its new specification for file-based programme delivery, is mapping its metadata to EBUCore and TV-Anytime. (TV-Anytime was co-founded by the EBU, who chaired the metadata activities and now actively maintains the specification on behalf of ETSI).

The work on EBUCore and EBU's CCDM greatly influenced the development of W3C Ontology for Media Resources, and vice versa. MA-ONT, as it is known, is a subset of the EBUCore ontology and the RDF/OWL representation rules are common to both. This work is also being used to propose extensions to the schema.org in order to describe TV and radio programmes and associated services and schedules.

EBUCore is also used as the solution for metadata aggregation in EUScreen, the European audiovisual archives portal and now a key contributor to Europeana, the European digital library. Two forms of EBUCore are used in this context, the EBUCore XML metadata schema and also the EBUCore RDF ontology.

Other on-going or planned activities using EBUCore include:
• EBUCore will be listed as a formal metadata type by the SMPTE. The EBU is arranging for software to be available to embed EBUCore metadata in languages such as XML or JSON.

• The NoTube project has combined egtaMeta (an EBU specification extending the EBUCore for the exchange of commercials) and TVAnytime to develop innovative solutions in targeting advertising.

• EBUCore is also used in combination with MPEG-7 in the VISION Cloud project exploring technologies for storage in the cloud. The EBU is directly involved in the definition and promotion of the new MPEG-7 AVDP profile.

• Singapore’s national broadcaster, MediaCorp, has implemented and adapted EBUCore/SMMCore into its internal company metadata framework.

• The EBU is engaged with several broadcasters for the adaptation of EBUCore in different contexts such as a common metadata format for file exchange.

The above is just a small selection of developments. For example, EBUCore is also republished by the Audio Engineering Society (AES) as AES60, and is available in XML, SMPTE KLV, JSON and RDF/OWL.

Watch this space as the EBU will soon publish a user-friendly EBUCore mapping tool on its website.

By Jean-Pierre Evain, EBU Technical Magazine

DPP Unveils Technical & Metadata Standards for File-based Programme Delivery

The Digital Production Partnership (DPP) – a partnership between ITV, Channel 4 and the BBC – has unveiled its new Technical and Metadata Standards for File-based programme delivery in the UK.

Through the DPP, seven major broadcasters (BBC, ITV, C4, Sky, Channel Five, S4C and UKTV), have all agreed the UK’s first common file format, structure and wrapper to enable TV programme delivery by digital file. These new guidelines will complement the common standards already published by the DPP for tape delivery of HD and SD TV programmes.

Working closely with the Advanced Media Workflow Association (AWMA) in the US, the DPP has been the driving force behind the creation of the organisation’s ‘AS-11,’ a new international file format for HD Files. The new DPP guidelines will require files delivered to UK broadcasters to be compliant with a specified subset of this new, internationally recognised standard.

By implementing one set of pan-industry technical standards for the UK, the DPP aims to minimise confusion and expense for programme-makers, and avoid a situation where a number of different file types and specifications proliferate.

The new DPP standards aim to remove any ambiguity during the production and delivery process. A key aspect is the inclusion of editorial and technical metadata, which will ensure a consistent set of information for the processing, review, and scheduling of programmes, as well as their onward archiving, sale and distribution.

As part of the file-based guidelines, the DPP’s member broadcasters have agreed a minimum set of common metadata to be delivered with a file-based programme. And, in a bid to encourage international adoption of its metadata standards, the DPP has worked closely with the European Broadcasting Union (EBU), mapping its minimum set of common metadata to existing ‘EBU-Core’ and ‘TV-Anytime’ metadata sets.

Alongside these new standards, the DPP is currently building a free-to-use, downloadable, metadata application to enable production companies to enter the required editorial and technical metadata easily. The new application is due to launch in spring 2012.

The agreement of these new file based technical standards does not signal an immediate move to file based delivery. Instead, the DPP seeks to provide clarity around digital delivery that will become the expected standard in the future.

During 2012 BBC, ITV and Channel 4 will begin to take delivery of programmes on file on a selective basis. Production companies wishing to deliver by file should discuss this at the point of commission, and seek formal agreement with their broadcaster at the outset of production. After a period of selective piloting, file based delivery will be the preferred delivery format for these Broadcasters by 2014.

Source: Digital Production Partnership

DPP to Release Metadata App

The Digital Production Partnership (DPP) will release a metadata application next year to help production companies comply with proposed file-based delivery requirements. The web-based app will allow production companies to enter a required set of metadata that is associated with a completed TV programme and wrap it into MXF files that are compliant with the cross-broadcaster group’s common standards.

“This will enable the creation of finished file-based TV programmes by independent producers for onward delivery to major UK broadcasters,” the DPP said.

The app, which was described as being compatible with common PC and laptop operating systems, is set to be rolled out during “spring/summer” next year.

From 2012 the BBC, ITV and Channel 4 will begin to take delivery of programmes as files on a selective basis. File-based delivery will be the broadcasters preferred delivery format by 2014. The common standard for the delivery of file-based programmes is set to be announced in by January.

Source: Broadcast

Rapid Adoption of ID System Speeds Multiscreen Rollouts

A simple but essential new pan-industry method for keeping track of entertainment content and the metadata that’s essential to monitoring usage and enabling navigation and other applications is already paying off in activities across the digital landscape. Known as EIDR (Entertainment ID Registry), the platform employs numerical IDs to provide a solution for identifying digital movie and TV content in commercial distribution, regardless of platform or distribution channel.

“The film and TV industry hasn’t been very good at tracking compared to what we see in retail stores,” says Jud Cary, vice president and deputy general counsel at CableLabs, one of the founding entities in the EIDR initiative. “What we’re doing is very similar to UPC (the Universal Product Code barcode system) in dry goods.”

People and applications alike can search the registry via Web user interfaces or Web service APIs using the numerical ID that’s been assigned to a given piece of content submitted by a content owner or other registrant to immediately access all the metadata descriptions associated with that content. The numerical tags create a uniform basis for tracking content usage and developers can use the APIs to integrate the registry features with their applications and automated workflows.

“When you’re trying to deliver content in multiple formats to multiple devices, it gets exponentially complex to keep track of each movie or TV program and to make the back office work efficiently,” Cary says. “You can have hundreds of permutations of a given piece of content once you start talking about clips, different cuts, different encoding and distribution formats.”

EIDR, which began over two years ago as a development project spearheaded by MovieLabs, CableLabs, Comcast and Rovi Corporation with backing from many individual studios and other entities, launched in early 2011 and now is anchoring content initiatives across the ecosystem.

“Complete, accurate and consistent metadata is key to our products and features such as browse, search, filter and recommendations,” notes Steve Heeb, vice president of business development at Comcast. “The use of EIDR will enable us to develop a robust and accurate database of program metadata from multiple sources that can be used across multiple platforms, including VOD, linear and online.”

A big advantage for content producers is the impact EIDR is likely to have on monetization, leading to more aggressive use of online distribution. “EIDR makes it easier for content producers to track and get paid for ad impressions and the use of their assets,” Cary says.

For example, Warner Bros. has invested in several technology initiatives to streamline and automate online interactions with retailers, vendors and consumers, says Darcy Antonellis, president of Warner Bros. technical operations. “EIDR is a key component of these initiatives, providing a global, unique identifier for content assets as they move from creation to consumption,” Antonellis explains.

“Just as our advertising colleagues have seen a need to use a unique ID system for ads, the need for a unique ID to track media and entertainment flowing online also has become obvious,” she continues. “We are actively integrating EIDR into our content workflow and are working with retailers like Microsoft to incorporate the standard over the coming months.”

Similarly, Disney has made EIDR part of its infrastructure supporting multiple digital initiatives, says Arnaud Robert, Disney’s senior vice president of distribution technology. “We have implemented EIDR into our metadata and internal digital workflows, and, working with our distribution partners, we intend to extend its usage to our various distribution channels,” Robert says.

Rovi, a major holder of metadata from movies and programming going back to the dawn of broadcast TV, played a major role in contributing records to “prime the pump,” Cary says. Comcast and others with significant data bases contributed as well.

The non-profit EIDR operation is designed to draw as much content into the database as possible, he adds. “The idea is the fees to join are so ridiculously low anyone can participate,” he says, noting that costs are tiered for contributors to where the highest level is only $5,000, which “gives you unlimited access and registrations.” At the promoter level, where the fee is in the $35,000 range, entities are entitled to be on the EIDR board.

An important new factor in driving participation is the support of two influential industry organizations – The Digital Entertainment Group (DEG), a Hollywood marketing engine, and the Hollywood IT Society (HITS). The two are working together to help drive adoption among studios, post-production houses and service providers.

Source: ScreenPlays

The Digital Production Partnership Announces Two Major Initiatives to Accelerate the Move to Digital Production in Television

The Digital Production Partnership (DPP) – a partnership between ITV, Channel 4 and the BBC – has today made two major interventions in digital production in Television. The first is the release of a report, The Reluctant Revolution – Breaking Down Barriers to Digital Production in TV. The second is the announcement of common Technical & Metadata standards for file-based delivery of TV programmes to all major UK broadcasters.

Painting a picture of a technical and creative revolution that is struggling to ignite, the report argues the reason is not the indifference or ignorance of producers, but rather the failure of broadcasters, suppliers and manufacturers to understand the practical realities and frustrations of the production community.

Gathering the views and experiences from a broad range of production companies across the UK, the report, commissioned by the DPP from industry analysts MediaSmiths International, concludes that for all the new technology of recent years, there is no easily workable and affordable model for end-to-end digital production available to independent producers.

“The move to end-to-end digital production is inevitable,” says the report, “but the pace of change is limited by the lack of clear signposts, or standard ways of working, and therefore a reluctance in the production community to set off on the journey… The key to ignition for this slow-moving revolution is the acceptance by all concerned of the day to day realities faced by production communities, and an understanding of where and how the benefits can be identified and achieved.”

The report identifies a number of opportunities and interventions that could bring about revolutionary change in digital production. These include pay-as-you-go models for web and cloud based tools and services, a new role for existing trusted providers such as facility houses, and a more pro-active role for the Broadcasters.

Mark Harrison, Controller of Production, BBC North and BBC lead for the DPP, said of the report and its outcomes, “Those of us who have been evangelists for the creative and business benefits of fully digital production have been mystified by the slow pace of change. This report explains that slowness, and offers practical suggestions for how change can be accelerated – not least by recognising that Broadcasters must get more involved.”

The second announcement made today reflects the commitment on the part of Broadcasters to get more involved: the DPP has unveiled the key features of its Technical & Metadata Standards for File-based Delivery, which will be published in full at the end of this year.

In response to producers citing ‘unnecessary complexity and lack of standardisation’ as one of the key barriers to digital production, the DPP, as a starting point to gaining greater simplicity, has clarified the UK Broadcaster’s technical expectations around file based delivery.

Through the DPP, six broadcasters have agreed the UK’s first common file format, structure and wrapper to enable TV programme delivery by file. These new guidelines will complement the common standards already published by the DPP for tape delivery of HD and SD TV programmes.

By agreeing one set of pan-industry technical standards for the UK, the DPP aims to minimise confusion and expense for programme-makers, and avoid a situation where a number of different file types and specifications proliferate.

The DPP has also worked closely with the Advanced Media Workflow Association (AMWA) based in the US, on a new standard for HD files. AS-11 is planned to be published by AMWA by the end of the year, and the DPP guidelines will require files delivered to UK broadcasters to be compliant with a specified subset of this internationally recognised file structure.

Key Features of the File Standard
• Designed for completed programme deliveries
• Based on the MXF file format, AVC Intra compression at 100 Mb/s for HD, and IMX at 50 Mb/s for SD
• Founded on a new AMWA international standard, AS-11
• Includes a minimum set of requirements for Programme Editorial and Technical Metadata

The common metadata standards, which form an important part of the new file-based delivery guidelines, have been developed with reference to the European Broadcasting Union’s EBU Core.

The new standards aim to remove any ambiguity during the production and delivery process. A key aspect is the inclusion of editorial and technical metadata, which will ensure a consistent set of information for the processing, review and scheduling of programmes. As part of this requirement, the DPP is planning to provide an application to enable production companies to enter this metadata easily.

Kevin Burrows CTO Broadcast and Distribution, C4 and DPP Technical Standards Chair, said, “Having one set of standards for file-based delivery across the industry is of huge benefit in ensuring ease of exchange. It will also reduce costs for independent producers as well as minimising confusion amongst programme makers.”

The agreement of these new 'file based technical standards' does not signal an immediate move to file based delivery. Instead, the DPP provides clarity now around which file formats, structures and wrappers will become the expected standards for file-based delivery as it is phased in.

From 2012 BBC, ITV and Channel 4 will begin to take delivery of programmes on file on a selective basis. File based delivery will be the preferred delivery format for these Broadcasters by 2014. This announcement represents long notice lead-time to the industry, and will enable production and post production companies to ready themselves for this transition.

Source: Digital Production Partnership

Metadata Exchange with BMF 2.0

Institut für Rundfunktechnik (IRT) announces the publication of the Broadcast Metadata Exchange Format (BMF) 2.0 Beta. BMF 2.0 is a rich metadata-vocabulary for the domains of television, radio and Internet. As a lingua franca in metadata exchange it facilitates the reuse of metadata and increases the interoperability between IT-systems.

The BMF model covers the information requirements of a wide variety of domains in television as production, planning, distribution and archiving. This is the result of an accurate evaluation of different use cases which was accomplished in close collaborations with working groups of the public broadcasting in Germany. Amongst others BMF 2.0 supports now the complete use cases of production-, program- and event planning, camera metadata and file transfer of program material.

Metadata in BMF 2.0 are exchanged as XML documents. The structure for the BMF-XML documents is defined in a XML Schema with clear and simple design rules. Furthermore the XML Schema provides faster orientation for developers through short documentation. The rich vocabulary of BMF 2.0 is a toolset for the generation of model-subsets for specific use cases. Only these subsets will be implemented.

The XML Schema of BMF 2.0 Beta can be downloaded by interesting companies for testing and evaluation purposes at free cost.

Metadata

By now, most engineers have heard that metadata refers to data about data. As facilities move from tape to files, and from tight integration to service oriented-media workflows, it becomes critical for engineers to have a solid understanding of this important topic.

The definition of metadata as “data about data” may be accurate, but it is perhaps not entirely useful. Revising the definition a bit, in our industry, metadata typically refers to data about the video and audio — the essence of the program. System designers have found it useful to distinguish between essence and metadata. But just as things are starting to become clear, someone may ask, “What about closed captioning? Surely that is data — right? How about time code?”

When talking about data in relation to video and audio, it is important to ask yourself whether the data you are talking about is part of the program (essence), or whether it is descriptive information about the program (metadata). Using this as a guide, we can classify different elements of a program as either essence or metadata. (See Table 1 below.)

Essential Metadata vs. Descriptive Metadata
The types of metadata are practically limitless. Metadata can include identifiers, time code, geospatial data and even free-form user metadata such as field notes entered by a camera person. That said, there are two main classifications of metadata that can be useful. The first is Essential Metadata. Essential Metadata is data that is critical in order to play the content. Examples include unique identifier, frame rate, compression coding parameters and time code. The second is Descriptive Metadata. Descriptive Metadata describes the essence. Examples include house number, title, program length, sponsor or advertiser, and ISCI code.

It is useful to divide metadata into these two classifications because, in cases where data storage space is severely limited, it may be that only Essential Metadata is stored with the content. As we move further away from legacy videotape-oriented systems, storage space for metadata becomes less of a problem.

In Table 1, some of these classifications may seem arbitrary. To some extent, this is true. Is AFD essence data or metadata? Is a house number Essential Metadata or Descriptive Metadata? It may depend upon the systems involved. While there is no definitive answer to these questions, the concepts of essence, metadata, Essential Metadata and Descriptive Metadata can be helpful as you learn more about this topic.

Media Identification
One can argue that the most critical metadata component is the identifier assigned to the essence. After all, once the tape is converted to a file, there are only two ways to identify the content — either by the file name or by an identifier that is closely associated with the content. Gone is the trusty label stuck to the cassette.

In many facilities, file names are used to identify the content of a file, and this can work very well. But there are some problems with this approach. First, in many cases, nothing enforces file naming conventions beyond a policy that has been established by the company. This is good because changing your naming convention is as simple as sending a memo or an e-mail. But this is bad because you are tied to the file name limitations of the operating system.

Another issue is that the file name can be easily changed. Again, this can be a good thing because some workflows may rely on the name of the file being changed once a QC check or some other step has been performed on the file. But this could be a problem because the workflow process relies on humans to correctly type the file name and to correctly change the file name as the work progresses through your system.

Finally, the strongest argument for not using file names for identification is that there is no guarantee that the file name is unique. This can cause some major headaches, which I will get to later.

In many master control operations, content is identified by a house number. House numbers are typically assigned by the traffic or programming departments, they are internally generated, and they are used by various computer systems to identify content in the facility. House numbers may be incorporated into file names, and they may also appear within the metadata of the file itself.

Unfortunately, most house number systems suffer from the same limitations as file name systems previously discussed. In fact, a long time ago, a station where I worked used the same house numbers over and over. The promo for the Friday night movie, for example, was always 50555. This system worked well until we accidently promoted last week's Friday night movie because no one had replaced the old promo with the new one. Even though we knew there was a problem with our numbering system, we continued to use it until we accidently played a national automobile commercial during the wrong week. I do not remember the particulars, but I do remember some very uncomfortable meetings over the issue. Finally, we stopped reusing house numbers and went to a different system.

The MXF standard specifies that Unique Media IDentifiers (UMIDs) be used as labels within the MXF file to uniquely identify the content. UMIDs are computer-generated 16-byte strings that can be locally generated, meaning that you do not need any outside references to create the UMID. Statistically, UMIDs are almost guaranteed to be unique. This means that it is possible to uniquely identify a piece of media no matter where that content came from. One rub is that UMIDs are not meant to convey any information at all in and of themselves. For many media companies, it can be challenging to stop relying on the media ID as a way to convey information about the content. But file-based workflows rely on unique identifiers. In fact, it is a key assumption that the identifiers are unique.

The topic of media identification in metadata is an important one, and I expect you will see more on this topic as more companies move to file-based workflows.

Metadata Synchronization
Recently, the industry has spent a lot of time focusing on metadata contained in file wrappers. This is great, because without some consistency in how we treat metadata, interoperability at the file level is impossible. But one question facing system architects is how we can ensure metadata synchronization. Remember that metadata is not only contained in file wrappers, but it is also contained in databases that are used in many places in our facility. What should we do when metadata is modified? Should we always strive to ensure that the metadata in the file header matches what is contained in the database? Since it takes time to modify metadata in file headers, should we only modify the file header metadata to match the database when we export the file?

Perhaps the best approach would be to write the minimum metadata to the file header and keep all the rest of the nonessential metadata in the database. This is fine, but some media facilities want to be able to rebuild metadata contained in databases from the metadata contained in the files in the case of a database failure.

There are no easy answers. Metadata is a complex topic, and thinking on this topic is evolving. As you transition to file-based workflows, it is a good idea to spend time with your vendors, understanding how metadata is treated in a wide variety of scenarios.

By Brad Gilmer, Broadcast Engineering

EBU Acquisition Technical Metadata Set

This version 1.0 of the “Acquisition Metadata Set” specification has been developed by the EBU’s Expert Community on Metadata (ECM), under the umbrella of the EBU HIPS Strategic Programme (SP-HIPS). The goal of this Strategic Programme has been to define solutions to improve interoperability in HDTV production (audio and video encoding, wrappers, metadata and SDI interfacing). HIPS-META is the SP-HIPS subgroup on metadata.

The “Acquisition Technical Metadata Set” is a set of metadata collected at capture through interfaces from live cameras or camcorders. It is intended to improve interoperability for the purposes of exchange of material. This set has been commonly agreed by EBU Members (users) and manufacturers for use in a tapeless file-based or live production environment.

The “Acquisition Technical Metadata Set” is clustered in camera device (shooting parameters), lens device (settings and identification) and microphone device (identification) video and audio metadata sets. This document only provides definitions of the different relevant metadata attributes.

For cameras and camcorders, it is expected that the file format used for the export of the essence will be MXF. The metadata structure should support the exchange of native available MXF (export) and XML (Import and export) formats. Additional EBU specifications provide implementation guidelines for different configurations (e.g. using KLV and XML encodings for exchange inside MXF files, or using separate XML files). Descriptive Metadata sets are also specified in a separate EBU specification.

More information on the role of this specification with regard to other related EBU metadata specifications is provided in the ‘metadata’ section of the EBU TECHNICAL website.

Metadata 3D Initiative

Metadata 3D Initiative (m3Di) is proposing a standard for 3D metadata communication in order to make interoperable lenses, cameras, rigs and stereoscopic image processors used in 3D productions, in a way that all the products accomplishing that standard, would allow final customers to replace any item of the production chain with no major impact in the 3D workflow, giving freedom of choice and ensuring interoperability.