Interoperability Issues between Pinnacle MediaStream and Omneon Spectrum Files
With Pinnacle having been a server vendor of choice for the best part of a decade, but broadcasters increasingly relying on Omneon systems for playout, there is clearly an important requirement to ensure interoperability between the two. Many broadcasters have several years’ worth of material stored on Pinnacle servers and are keen to ensure it does not become obsolete and that all the time, money and effort spent on ingesting that media is not wasted.
Unfortunately, however, while many transcoding system vendors claim to be able to handle file conversions between Pinnacle and Omneon, the reality is that only the video portion of files can be exchanged with any ease; conversion of audio and Vertical Blanking Interval (VBI) or Vertical Ancillary (VANC) information is almost invariably prone to errors, due to a number of important differences in file format including the following:
Owing to the above and other differences in file format and structure, converting Pinnacle content for use with Omneon systems will typically lead to one or more of the following issues:
- Files will not load
- Files will load but not play
- Audio ‘popping’
- Lack of audio-visual synchronization
- Loss of Dolby E audio
- No closed captions
- Closed caption synchronization problems
- Time code non-existent or not synchronized to video
These problems are potentially more difficult to solve in certain lesser-used formats, such as uncompressed audio in standard definition or high definition sources. And incompatibilities exist in both transcoding directions; in other words, it is as difficult to get a Pinnacle server to work with Omneon files as it is to do the reverse.
To compound the issue, there are interoperability problems within the Pinnacle product range itself, so that files created with one version of MediaStream might not always work with another version.
The available options
As stated above, the amount of content that a broadcaster might hold in Pinnacle format can be quite significant: for example, Turner Broadcasting holds about 2,200 hours of programming that needs to be converted. Assuming the broadcaster does not simply want to let this content become obsolete along with the Pinnacle platforms that it uses, there are three options for conversion:
- Playing out the content to baseband from Pinnacle servers and re-ingesting it directly into Omneon systems in real-time. Apart from drawbacks such as loss of metadata, it is fair to say that this approach is simply not cost-effective for any but the smallest of archives.
- Carrying out conversions using traditional transcoding systems. As noted above, this would inevitably lead to a loss of metadata and audio information, and a consequent reduction in quality. There may be some situations where such a reduction is bearable although, again, this is only likely to be so in very small number of situations.
- Implementing a workflow that can offer industry-leading video transcoding and at the same time handle the conversion of audio and metadata in a robust, automated and, ideally, faster-than-real-time fashion.
Flawless conversion
AmberFin has achieved flawless conversion between Pinnacle and Omneon video, audio and metadata using standard iCR software and a constrained application specification of MXF. This process also addresses incompatibility issues on the Pinnacle platform itself.
MXF provides a universal open-standard wrapper which can take care of the ‘heavy lifting’ of essences from one platform to another. The constrained specification, called MXF AS02, is being developed by a joint team of users and vendors within the Advanced Media Workflow Association for submission to the Society of Motion Picture and Television Engineers (SMPTE) in 2008, with AmberFin, a member, playing a key role.
MXF AS02 has been designed to get around the incompatibilities that have arisen as different parts of the generic MXF standard have been implemented in practice.
MXF was chosen over QuickTime as the conversion medium between Pinnacle and Omneon because it is more suited to integration into automated workflows. For example, MXF’s structure includes a program version file which references the program contents. In a situation where, for example, a Web service application has to query an MXF file before processing it, the application need only check the version file, which usually has an average payload of about 20 kilobytes per asset. With QuickTime, in contrast, the application would need to be sent either the entire asset or a reference movie with weak links to the content. Sending the entire file could require a copy of 5 to 50 Gigabytes, increasing bandwidth requirements by a factor of 100,000. Sending the reference movie, meanwhile, does not transmit enough information for the Web service to know everything about the asset. Only MXF provides this level of detail.
Benefits of MXF AS02
Because of its non-proprietary nature, MXF AS02 offers a number of benefits as a generic medium for media servers. To take just one example, it is based on the SMPTE 436M standard to store VBI/VANC packets, rather than the proprietary mappings for VBI/VANC data lines, including closed captions, still used by many systems today. This greatly simplifies captioning, as all data can simply be provided in the standard 436M format instead of having to be adapted to the proprietary requirements of different types of server.
Similarly, because SMPTE 436M VBI/VANC data can be decoupled from and re-coupled to the MXF wrapper, there is no need to send the entire MXF file through for captioning; instead, the work can be carried out just on the 436M file, again reducing the bandwidth requirements of the workflow.
The paper specification for MXF AS02 is now fairly robust and furthermore is oriented towards decision makers who have to write and respond to Requests For Information (RFIs), making it a highly accessible standard. A number of vendors, including AmberFin, Omneon, Marquis Broadcast, TransMedia Dynamics (TMD), EMC and Pro-Bel, already have working MXF AS02-based systems and Turner Broadcast is using it to convert between Pinnacle and Omneon directly on demand.
MXF AS02 and AmberFin iCR
While the MXF AS02 specification provides a convenient wrapper for file transport between Pinnacle and Omneon, the critical conversion functions are down to AmberFin iCR. The iCR system is designed for maximum automation and interoperability so that once a conversion profile has been set by an operator the system can reproduce it exactly on request without further intervention.
Furthermore, the system is capable of carrying out flawless conversions between Pinnacle and Omneon files at four times faster than real-time and without any additional bandwidth requirements, effectively making it possible to mix and match Pinnacle and Omneon servers indiscriminately with iCR acting as universal translator. The speed of conversion means Pinnacle files can be called up and played out on Omneon servers on the fly. Similarly, Pinnacle archives can be updated to Omneon-friendly MXF format in the background during periods of low server utilization.
The conversion can be carried out in both directions, too, so that for example material can be ingested on an Omneon platform and then played out on Pinnacle, or even stored on Pinnacle and played out again on Omneon.
Last but not least, as indicated above MXF AS02 has the potential to become a universal format for different server platforms and iCR offers unrivalled automation and integration possibilities, both of which mean the iCR/MXF combination have benefits far beyond simple transcoding between Pinnacle and Omneon systems.
Summary and conclusions
Converting Pinnacle files into a format useable by Omneon servers, and other versions of Pinnacle, is a growing problem in the broadcast industry and one that is related to a wider issue of server platform incompatibility. Using MXF AS02 as a universal wrapper and iCR as a conversion engine makes it possible to overcome the issue of interoperability between Pinnacle and Omneon, and at the same time points the way to a much wider level of compatibility between server vendors.
Source: Amberfin
