File-based workflow, Part I
Apr 1, 2010 12:00 PM, By John Luff
Bits and bytes made into programs.
We are officially in a file-based world. That is not a shock; we have been moving that way for years. Now even cameras are spoken of as recording files, so I guess we have crossed the equivalent of the Rubicon. When Caesar crossed that celebrated river, he broke a Roman law. Progress in several technologies helped our industry to make this transition more than 20 years after nonlinear editors began working with files in earnest.
This first installment of a two-part series will look at the underpinnings of what is generally called file-based workflow, defining terms and setting the reference points in the discussion. Make no mistake: Using files instead of physical media is a radical change in how we work. British writer Sidney Smith said, “To do anything in this world worth doing, we must not stand back shivering and thinking of the cold and danger, but jump in, and scramble through as well as we can.”
Key concepts of digital content
The change mentioned above is brought on by embracing the digital nature of content, which is well described in the book “Being Digital” by Nickolas Negroponte.
There are three overarching concepts, spelled out more than a decade ago by the EBU/SMPTE Task Force on Harmonized Standards for the Exchange of Television Program Material as Bit Streams over a decade ago. First is essence. Essence is the content of a program, video and audio, and perhaps data for interactivity or other applications. Second is metadata, which most simply put is bits about the essence. It describes the content in ways that will allow a user to decode and use the essence. It might, for instance, describe the encoding used (MPEG-2, H.264, JPEG2000), the number of audio tracks, program rights information and even GPS coordinates where it was shot. Third is the idea of a wrapper. The wrapper surrounds the essence and metadata. It allows for parsing of the content and metadata to decoders in an efficient manner without requiring a multiplicity of files loosely coupled and difficult to manage. Wrappers are familiar to us, including MXF (Material Exchange Format, standardized by SMPTE), AVI and QuickTime.
It might be useful to look at another analogy. SDI and HD-SDI are similar to baseband wrappers. They carry video and audio, as well as metadata. There are important differences, however. SDI (and HD-SDI) does not announce the presence of services. Audio is always in the same place in the signal, so if a decoder is looking for audio, it knows where to look. Metadata is a bit less obvious, but as with audio, it does not announce its presence. One must know what to look for and where. With wrappers in file-based operations, the wrapper announces what is being carried and points to where it is. Thus, each file is self-referencing. As soon as it is received, an application can inventory the contents of the wrapper and disburse information to other applications as needed. (See Figure 1.)
Another key concept is that dubbing content to make copies is no longer appropriate. When you copy a file, you create another instance that's totally indistinguishable from the original. If a file is altered, perhaps with closed captions, or maybe the content is edited, you create a new version. Managing the multiplicity of instances and versions can be one of the more difficult aspects of a file-based facility. It requires a good asset management system to fully track versions and instances (and instances of versions). Later, I'll discuss some tools that allow complex descriptions of content to be part of the wrapper in ways that facilitate standardized program interchange and flexible creation of versions from a set of related essence elements.
Another important, though obvious, point is that all file-based facilities are network-based, IT-centric installations. That is not to miss the point that some aspects of a file-based world need to bridge to the linear analog world. Ingest in news is an obvious example of a hybrid workflow where file-based and linear worlds must merge seamlessly into a whole. Most release-to-air facilities similarly are in the hybrid camp. It is critical to understand that a file-based workflow is inherently not synchronous and time-dependent; it is asynchronous and loosely, if at all, coupled to time. There are methods of treating files as time-dependent entities, most clearly thought of as streaming.
Generally, networks deliver best effort movement of content, which is not a great way to run master control. To get beyond that, one really needs to do a good job of designing applications and controlling the architecture of the network on which the system lives. When this is done well, it works transparently.
The issue of synchronicity is central to many discussions about file-based workflow. Master control must deliver content reliably concatenated and locked to a delivery time. The goal of file-based master control is to provide the illusion that the content is seamless and continuous. To do that in the DTV world means that metadata must be delivered with essence. Even embedded metadata, such as dialnorm and DynRng, are tricky to deliver in a complete system. Consider the case of a fade between two sources. Picture and sound are easily handled, but how does one transition metadata? Most implementations today pick a point in the essence transition and simply chop to the new source of metadata, a decidedly inelegant answer to a growing problem. The same problem exists in AFD and other classes of metadata.
There is a second problem with metadata management that is not immediately obvious. There are times when metadata needs to be separately processed, such as when rights information is updated. That means bytes need to be copied out of a container, transmitted to a program where they are modified, and later replaced in the original file, or perhaps a new version. It is possible that two operations are happening at the same time, leaving a complicated resyncing of metadata to be done. In the last few months, work has begun on a standard way to communicate that metadata, likely based on the SMPTE BXF standard. The data is XML code, which is what BXF is built on, so this appears to be a logical approach.
Continue to next page.
| Want to use this article? Click here for options! |























