This page contains a Flash digital edition of a book.
April 2012

TVBEurope 29 Media Asset Management

with another line drawn on another piece of paper? MAM continues to be

associated with major change within adopting organisations. An excess of constraints and ‘unique to us’ in MAM requirements can be an indication that the organisation itself is resistant to change and may be missing out on potential benefits as a result. A rule of thumb used to be that 33% of a major MAM project budget might need to be set aside for what was effectively custom coding by the manufacturer. Such proportions are now, thankfully, diminishing.

Watching the cloud go by You recall the old joke. Question: What’s got the biggest bandwidth in London’s Soho post district? Answer: The courier’s white van full of video tapes! Broadcasters have been

wrestling for many years now with the logic of giving their content ‘crown jewels’ to third parties for off-site storage. A serious decision for finished or archive assets — essentially static items, with access required relatively infrequently. Doing the same for work-in-

progress (WIP) content, with it needing to be accessed on a far more interactive basis, by multiple users, remains a challenge. 'Intermediate' solutions have been built and operated successfully for proxy editing, with transfers and/or remote conforming of corresponding hi-resolution content — but there are few signs that customers or suppliers expect interactive, frame-by- frame manipulation of high resolution content held remotely to happen anytime soon. The recent ‘glitch’ in the

BBC’s collaborative production system at Salford Quays, where up to 30 edit seats were affected by a crash in central storage, serves as a reminder of just how badly behaved entirely locally- based MAM systems can be. Cloud computing will

continue to evolve. It already represents a viable way forward for the corporate IT software application layer. No particular stretch perhaps when the smartest thing this layer has to interact with is an office printer. MAM software applications

however are still tightly coupled to adjacent production and broadcasting tech and to Gigabytes and more of content. Trying to run before we can walk, forcing our requirements and solutions skywards, could

easily result in operations mired in expensive and practically useless Service Level Agreements (SLA) that can neither run nor walk come the next video frame.

Transcoded but not cured Conceptually MAM remains the straightforward proposition it has been since the term was coined well over a decade ago: simply about what content you have; where that content is; and whether you can use it. Of course, a simple glance through any list of exhibitors in an industry show catalogue will reveal the full extent that suppliers have bent, stretched and generally re-written the above definition to suit their products and position in the market. Customers too have pulled the straightforward proposition of MAM into different directions to suit their specific objectives, usually around the need for improved overall workflow and business efficiency. The practical reality of MAM

however remains stubbornly complex. Chief among the technical issues that continues to hound MAM implementations remains that of ‘formats’. At BVE 2012 in February, Andy King from Vision Productions, BBC, delivered a presentation entitled: “Is 100Mbps enough for broadcasters?”. In this presentation, King opined that the choice of codec defines everything. It determines quality,bandwidth and storage.

Andy King: The “plate of spaghetti” the industry sits in front of on a daily basis consists of a bewildering mix of 20, or more, codecs

parallel access to recorded content for processing and/or to take advantage of the unique features of some particular piece of station apparatus. Today, transcoding has

emerged as the necessary evil that has replaced tape copying. It's mostly automated, thankfully, but it still takes time (and not an negligible amount, particularly for HD) and requires significant investment in hardware, software and integration to MAM and other

everything’ approach. Fortunately, the shrinking physical size (and cost) required for storage of file-based content supports and encourages such an approach, but there are other factors to be considered too. At some future point in time,

that content you have on your shelf, held on a videotape, will not be playable. This will be due to there being no machines left on which to play it, or else the cost of access time for the one machine left in the world that

A rule of thumb used to be that 33% of a major MAM project budget might need to be set aside for what was effectively custom coding by the manufacturer. Such proportions are now, thankfully, diminishing

He also reminded the audience that the “plate of spaghetti” that the industry sits in front of on a daily basis consists of a bewildering mix of 20, or more codecs, combined with an easy half-dozen acquisition physical file storage formats, combined with another good half-dozen production/ broadcasting related functions, such as viewing, logging, editing, colouring. Back in the day, copying of content between videotapes (with comparatively few tape formats involved) was the norm. This was the sole means to facilitate

systems. While transcoding massages the symptoms, the industry continues to search for a cure in what has become an ocean of format choices. Progress?

Future-proofing and Play-ability If the growth in the (digital) broadcasting side of our industry has taught us anything in the past 15 years, then it must surely be that content pulled from archives can be exploited to make money, but knowing which content … well, that is only truly possible with hindsight! This leads us logically to the adoption of a ‘save

can play it being judged as too high. Nobody is going to make a new machine when all the machines are gone. If you have not migrated that content to some other format that is still playable by such time, then the content will become lost and your opportunity to make money from it also lost. Let's not forget that this is true in the file- based content world also. How many of us can today open a file produced on a word processor 25 years ago and make use of its contents?

Nothing lasts forever, so it is vital that the industry gets to

grips with automated migration of content and avails itself of open formats (including codecs — there they are again!) to ensure use at any time in the future. The former will increasingly be expected of MAM and is an area that remains as yet largely undeveloped.


MAM in 2012 is in good health. Customer MAM projects remain crucially important to business operating efficiency. These are supported by a market offering products that are diverse and capable. MAM functionality has become tactically aligned with and subsumed into media software products of all types, especially those for taking in, storing, manipulating and outputting file- based content. The 'usual suspects' industry brands have voted and see MAM as needing to be owned by them. They are taking the necessary corporate steps to make this happen.

There is much work still to do by the industry that will help MAM to become even more beneficial than it already is. Key to this is manufacturers of product, especially of cameras, recorders and editing systems decoupling product functionality from particular codecs and moving away from an excessive focus on formats as a key plank of their product differentiation strategy. Will NAB see any bold moves in this area? Watch this space! Mark Hill

Page 1  |  Page 2  |  Page 3  |  Page 4  |  Page 5  |  Page 6  |  Page 7  |  Page 8  |  Page 9  |  Page 10  |  Page 11  |  Page 12  |  Page 13  |  Page 14  |  Page 15  |  Page 16  |  Page 17  |  Page 18  |  Page 19  |  Page 20  |  Page 21  |  Page 22  |  Page 23  |  Page 24  |  Page 25  |  Page 26  |  Page 27  |  Page 28  |  Page 29  |  Page 30  |  Page 31  |  Page 32  |  Page 33  |  Page 34  |  Page 35  |  Page 36  |  Page 37  |  Page 38  |  Page 39  |  Page 40  |  Page 41  |  Page 42  |  Page 43  |  Page 44  |  Page 45  |  Page 46  |  Page 47  |  Page 48  |  Page 49  |  Page 50  |  Page 51  |  Page 52  |  Page 53  |  Page 54  |  Page 55  |  Page 56  |  Page 57  |  Page 58  |  Page 59  |  Page 60  |  Page 61  |  Page 62  |  Page 63  |  Page 64  |  Page 65  |  Page 66  |  Page 67  |  Page 68  |  Page 69  |  Page 70  |  Page 71  |  Page 72  |  Page 73  |  Page 74  |  Page 75  |  Page 76  |  Page 77  |  Page 78  |  Page 79  |  Page 80  |  Page 81  |  Page 82  |  Page 83  |  Page 84