feature automation & asset management
There is a great deal of debate about asset management at the moment. Much of it is around the prospect of a universal, common schema and set of standards. While this idea is superficially attractive, I would suggest that in practice it is never going to happen, and moving this way is taking energy away from realising the true benefits of asset management. Ed Casaccia, director of product marketing at Grass Valley, reports.
Amanageable approach to MAM L
et me start by taking two steps backward. First, I think we would all agree that much of the technology behind broadcasting is making a fundamental move away from purpose-designed black box hardware and towards the use of standard IT platforms.
In some areas this is overt and widely recognised. Few people coming into the industry today would even recognise an ‘edit controller’. Editing is performed on a standard PC or Mac, using EDIUS, Final Cut Pro or one of the many other software packages available today.
Other products have commodity IT under the hood. When Grass Valley launched its K2 media server in 2005, we made a particular point of emphasising that it used standard IT technologies and techniques, tuned where necessary to deliver the bandwidth, performance and, most important, reliability that professional broadcasters require.
Another example is the use of standard interfaces. Camcorders may still rely largely on custom-made hardware internally, but the material is delivered over widely recognised interfaces such as USB. The broadcast
24 l ibe l january/february 2011 l
www.ibeweb.com Ed Casaccia,
director of product marketing at Grass Valley.
world now relies heavily upon the IT industry, and of course benefits greatly from the massive R&D budgets available.
What made it possible to use commodity IT to handle broadcast signals, of course, is the now universal use of digital signals. Given a fast enough processor, HD video can be treated as a stream of bits and bytes in much the same way that email or word processing is. It is stored, handled, and delivered in the form of digital files.
The second point on which I am sure we agree is that file-based infrastructures are a good thing. They give us efficiencies in storage, we can move content when traffic allows it, freed from the tyranny of realtime links, and we can share it between multiple users. It has enabled collaborative workflows and multi- platform delivery.
What it has set us, though, is a challenge: in keeping track of what content you have and where it is. One of the attractions of the Betacam tape format was that the box was big enough to write on the label and to cram a sheet of A4 paper inside. Anyone can file the tape and know what it contains, because it says so on
the box. If you know what you are looking for you can go straight to the tape you want.
When the content is just a set of ones and zeros on a disk - probably on more than one disk in a Raid - you cannot just read the label. You have to have some means of knowing what content is where: an asset management system.
It is at this point that, some say, there should be an enterprise-wide asset management system, and perhaps a universal asset
management solution: a standardised metadata dictionary and schema. That, I would suggest, is an impossible dream: to create a single dictionary would result in something so vast that it would be unmanageable. It also risks being so large that it gets in the way of productivity. If each exchange of content starts with a preamble in which a lot of irrelevant data has to be swapped it is inevitable that bottlenecks will be created and errors increase - if, indeed, the exchange is successful at all. One of the problems with metadata standards is that there are too many of them. Each class of equipment and each stage in the workflow has different metadata requirements. It surely is
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