Tracking Media Assets In A Shared-Storage Production System
1. 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.
Tracking media assets in a shared-storage production system Revision 1.2 Page 1 of 6
2. 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.
Tracking media assets in a shared-storage production system Revision 1.2 Page 2 of 6
3. 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.
Tracking media assets in a shared-storage production system Revision 1.2 Page 3 of 6
4. 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}
Tracking media assets in a shared-storage production system Revision 1.2 Page 4 of 6
5. 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.
Tracking media assets in a shared-storage production system Revision 1.2 Page 5 of 6
6. 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 Revision 1.2 Page 6 of 6