Tracking Media Assets In A Shared-Storage Production System

Tracking media assets in a shared-storage production system Revision 1.2 of 6

Tracking media assets in a shared-storage production system

Why a robust Identity model is essential Trevor Francis, Worldwide Marketing Manager (Broadcast) Quantel Ltd, Newbury UK 25th November 2009

Introduction In the 1990’s it was sufficient for a central storage and editing solution to be able to capture, hold and distribute video and audio to multiple editing and playout stations. The level of metadata which could be applied and tracked was minimal; limited, perhaps, to a clip title, creation date, file size and one or two other text-based fields. As the capabilities and the size of the solutions grew, so did the requirement for descriptive information. An individual producer might have coped with minimal electronically-held data, supplemented with some hand-written notes, but a large enterprise certainly couldn’t function efficiently in this way. Extended metadata models developed to meet this demand; some have been more successful than others. Now, as national and multi-national organisations require the ability to create, share, repurpose and distribute content as widely as possible, the requirements have changed again. Their strained and evolving business models demand that they monetise all their assets to the fullest extent, using every distribution platform available. This has extended beyond traditional television to web-sites, podcasts and mobile devices as well as permanent storage media like DVDs, BluRay and CDs which we still buy.. Historically, broadcasters have had only a one-to-many relationship with us, the consumers, via traditional broadcasting mechanisms. It was easy for a broadcaster to report what had been broadcast and when. The internet is opening up possibilities for one-to-one business relationships - where I, as a viewer, may request current or back-catalogue content direct from the broadcaster. There is no reason to confine this to complete items of finished programming either; I may wish to see a selection of favourite scenes from a Soap or even to conduct my own research in their news archive. To meet their obligations to rights owners, broadcasters need a mechanism which can trace an asset through layers of editing; through many versions and forms; from one location to another. They cannot sell an asset unless they can trace the ownership of all the component parts and compile a record of every instance where that content has been used or sold. This is almost impossible unless we can define and assert a property which defines an asset itself. Not just a description, however rich, but a unique property, like DNA, which is both immutable and traceable wherever that asset appears. Quantel calls that property ‘Identity’. The Quantel architecture is built around an Identity model which enables us to identify and trace every frame of video and every sample of audio contained within every media file we manage.


File-based workflow The age of pure video-based production is clearly drawing to a close; the benefits of file-based acquisition, storage and processing are well accepted. But the fusing of elements of many source files into new and unrelated post-produced files creates its own problem. A standard consumer filing mechanism, like Windows, does not maintain a relationship between parent and child files. Consider this simple example of a pair of documents produced on word processors:

Original.doc Edit.doc Original.doc contains three paragraphs, including the middle ‘blue’ section. If I cut and paste the blue section into a new document, add a red section and save this new document as ‘Edit.doc’, then there is no relationship between the Original and the Edit. Anyone opening the Edit.doc file would have no idea where the paragraphs had come from. To complete the analogy, if the documents are printed on paper or converted to a distribution file format, like PDF, then the ‘files’ become totally flat. Flat files cannot easily be re-edited and all traceability of their provenance is gone. So what has happened here? Original.doc is a file. It contains three paragraphs of text, each of which has meaning and value. But the word processor has no mechanism to register and trace these paragraphs as entities in their own right. They have become flattened into a single file. If I need to track every use and re-use of a piece of intellectual work, like the blue paragraph, I need to give it a unique identity and I need a mechanism to carry that identity from one piece of editing software to another and from one piece of storage to another. So let’s develop this analogy and move closer to the world of moving pictures and sound. Here is a media file, Original.clip, containing three scenes, Red, Green and Blue.

We can imagine an edited version of Original.clip where we have deleted the Red scene. This new file is saved as Edit.clip. If we also imagine that the rights owners of these three scenes are the Red, Green and Blue companies respectively, then how can we ensure that we track this information through the production process and pay for the material we have used? Our example of the word processor paragraphs has already suggested that we need to establish an identity for the discrete elements in the original work. The next section will describe how Quantel systems create and maintain that identity.


An identity model for video files Returning to our source media, Original.clip, this is how Quantel-managed storage asserts identity on a media asset.

First, a mathematical algorithm creates a Globally Unique Identifier (GUID). In reality this is a long alpha-numeric string but may be represented by the simpler form shown above. For our systems to function in a joined-up world it is clearly unacceptable to rely on the human-generated clip title; we must have a reference which is guaranteed unique for all time and across all geographies. The GUID does this. The GUID gives us a reference for the file, Original.clip, but it does not help us with the three scenes contained within it. We could address this by counting the video frames from the start and noting the offset where each scene starts and ends. So, in this example, Original.clip can be represented thus:

001A 456B 789C {Start 0; End 100} The Red scene 001A 456B 789C {Start 101; End 200} The Green scene 001A 456B 789C {Start 201; End 300} The Blue scene

Now we have this model, we can express our edit in the same terms:

001A 456B 789C {Start 101; End 200} The Green scene 001A 456B 789C {Start 201; End 300} The Blue scene

In this example, we, the human users, have convenient text-based clip names and the machine has a robust model to represent every piece of content via a unique set of reference numbers. These references can be passed easily from one process to another using a simple mechanism such as XML. It is easy to see that the edited clip contains two sequences taken from the same source clip. So, imagining ourselves as the Asset Management system, we can trace the source file to destinations or the edited file to its sources. Just like DNA in humans, identity enables us to trace a clip back through its parents and grandparents and, conversely, to build a family tree to show how the genes of an original file are distributed through its children. In real life of course, we do not know when we acquire a file that it contains discrete scenes, but we do know that it contains discrete video frames and audio samples. So the Quantel management model is designed to work at this level of granularity, allowing the users to add the metadata which describes the scenes, the rights owners and so on.


In a real Quantel system our file, Original.clip, will be modelled like this:

Each of the 301 frames of video has an identity which is expressed as: 001A 456B 789C {Offset n} where 0 ≤ n ≤ 300. The first operation by a user may be to log the content – to mark the three scenes.

Metadata can be attached to a single frame or to a range of frames. Anywhere those frames are subsequently used, that metadata will be visible. So an imaginary database record for the file Original.clip might look like this: GUID: 001A 456B 789C Title: “Original” Type: .clip Length: 301 frames Owner: Red Company {Start frame 0; end frame 100} Green Company {Start frame 101; end frame 200} Blue Company {Start frame 201; end frame 300} Description: Red Scene {Start frame 0; end frame 100} Green Scene {Start frame 101; end frame 200} Blue Scene {Start frame 201; end frame 300}


Returning to our Edit.clip one more time, we can create a rich ingredients list or ‘manifest’, based on the Source.clip information in the database.

GUID: 019F 779E 631A (It has a GUID of its own) Title: “Edit” Type: .clip Length: 200 frames Source1: 001A 456B 789D {Start frame 101; end frame 200} Source2: 001A 456B 789D {Start frame 201; end frame 300} The manifest, which refers back to the original frames (Quantel calls them ‘Rush Parts’), allows us to track the metadata entered when the source clip was logged. So we can trace, for example, the rights ownership of every frame in the edit. We can easily discover that the two scenes are owned by the Green and Blue companies, respectively.

Frame magic This clip model allows us to build a really useful feature which greatly simplifies media management and automatically protects edited work from accidental deletion. We can create another table which holds a record of the number of times every frame is used. Let’s build this table for our file, Original.clip. GUID Offset Usage count 001A 456B 789C {Start frame 0; end frame 100} 1

{Start frame 101; end frame 200} 2 {Start frame 201; end frame 300} 2

The first sequence, the Red Scene, is used only in the Original file, so has a count of one. The second and third sequences, the Green and Blue Scenes are used in the Original and the Edit, so they have a count of two

So if we decide to delete the Original file, to create some storage space, the Quantel management routine will examine the usage count for every frame and delete only those with a usage count of 1.

Human users will see the file ‘Original.clip’ disappear from their media bins but the Quantel database will retain the rush parts with GUID 001A 456B 789C, between frames 101 and 300. All dependent clips are therefore preserved and the metadata relating to these ‘rush parts’ is kept too. Quantel has named this media management tool ‘FrameMagic®’, recognising its value to media managers and system users.


Conclusion Quantel’s Identity model is the foundation for an effective internal media management scheme, as illustrated by the ‘FrameMagic®’ principle above. More importantly, perhaps, it is a model which can be shared with Asset Management systems, third-party editing software and any other entity which requires unique references to stored media. The next paper, “Sharing Identity between storage and editing systems”, will describe how the Quantel identity model, alongside our file virtualisation technology can be built into a powerful cross-platform, multi-vendor, geography-independent production and distribution solution.

Tracking Media Assets In A Shared-Storage Production System

Documents

Transcript of Tracking Media Assets In A Shared-Storage Production System