Informative References Essence is the raw video, audio, and data streams contained and described by MXF. Metadata carried by MXF includes structural metadata and descriptive metadata.
Structural metadata relates to the structure and capabilities of the MXF file and is generally required for proper decoding. Some examples of structural metadata are descriptions of essence types, information to help synchronize playout of audio and video, and content length.
Descriptive metadata gives information about the program content in the file and is not essential for decoding. Some examples of descriptive metadata are program title, actors, and scene descriptions.
The essence in MXF files may itself carry data, such as vertical blanking interval data used for carriage of Closed Captioning and other purposes.
MXF is an important tool in providing interoperation between different video systems as well as digital cinema systems. MXF also aids in the development of video production and distribution workflows that are more efficient, multi-vendor, file based, and IT oriented.
The flexibility of the MXF generic container allows for the possibility of mappings of additional essence types in the future. The media type defined here is needed to correctly identify MXF files when they are served over HTTP or other network connections, included in multi-part documents, indexed by operating systems and digital asset management systems, or used in other places where media types are used.
The registration uses the template present in [ RFC ]. It is flexible and contains no real constraints on file construction rules. This makes its implementation quite simple. On the downside, this high level of vendor flexibility also means that interoperability can suffer when different vendors interact for the first time. On the down side, it is specified to have a maximum of eight channels of mono AES audio and even with these constraints, interoperability issues remain.
It is highly constrained; it only allows one component and all the synchronization of the components is done in the AAF file. Panasonic's P2 system also uses OP-Atom to record the actual video essence and audio essence. The P2 format is constrained, with good interoperability and extensible use of metadata. However, there are certain limits in the P2 file size, which can cause operational problems. There is another variety of componentized MXF that is used by digital cinema, which uses yet again a different way to synchronize files called composition play list CPL.
While it is an extremely constrained format that is well-suited for all aspects of digital cinema delivery, it is limited to RGB color space and JPEG , which makes it too constrained for a general purpose interchange format and unsuitable for TV workflows. As we are starting to see, in spite of the best efforts of the MXF standard to ensure seamless interoperability among the various vendors, the various flavors of MXF are still leading to incompatibly issues.
And while interoperability is improving as manufacturers are learning how to better implement the standards, users continue to experience some frustrations created by incompatible systems that can't read each other's MXF files. This problem has led to renewed collaboration between media companies including AmberFin and a dozen other vendors through AMWA to draw up some application specifications AS as the basis for simple, easy interoperability. The application specifications are not particular to any one vendor.
They define a set of constraints on how the file is constructed to match the operational and technical requirements at a particular point in the workflow. MXF AS and AS, for instance, have been designed to streamline file-based workflows within and between organizations. AS is a mastering tool; it is designed to meet the needs of content creators and distributors who face program versioning challenges.
With AS, video, audio and data are stored in separate media files to enable efficient versioning of programs for distribution. A bundle is completely self-contained and holds all the assets and metadata needed to generate several versions of a program for use in a multiversion, multilingual, multidelivery media environment.
Today, we have good read support for this format, but write support is lagging behind. The structure of AS can make multiversion workflow quick and produce light loading on a facility's network infrastructure.
MXF AS is intended for delivery of finished content directly to a playout server. AS constrains the MXF toolkit to efficiently carry final deliverables in a compact, robust and directly playable format.
An AS file is always a single file, for a single program. The content of these files is not intended for further processing before delivery to the viewer but for direct playout from any server. Embed the XML file Further documentation about the workings of the SDK, its use and developer documentation is available in the following resources:.
Licensed under the Apache License, Version 2. You may obtain a copy of the License at. See the License for the specific language governing permissions and limitations under the License. Skip to content. Star Branches Tags. Could not load branches. Could not load tags. Latest commit. Git stats commits. Failed to load latest commit information.
View code. Documentation License.
0コメント