MXF Expert

Material Exchange Format plus Descriptive Metadata

C++博客 首页 新随笔 联系 聚合 管理
  3 Posts :: 0 Stories :: 1 Comments :: 0 Trackbacks

2011年1月11日 #

Please see this website for a very nice workflow chart.

http://www.mxf-solutions.com
posted @ 2011-01-11 15:01 Eric(MXF) 阅读(343) | 评论 (0)编辑 收藏

2010年11月6日 #

SMPTE 380M "Material Exchange Format - Descriptive Metadata Scheme-1" has been out for years, but still not really widely used in the broadcasting industry. The most important reason is that there is not a clear specification of how to map the real world metadata to DMS1. One good example is the disscussion in the "MXF Expert" group of www.linkedin.com about how to use "Key frame" in MXF.

There are three common ways to carry Descriptive Metadata in MXF files.

1. Using non-referenced KLV (of course a unique key). An example is SONY XDCAM files. SONY puts their XML metadata in to MXF file as a KLV chunk, which is not referenced (linked) by any other KLVs in the file. This actually violates the rule of how MXF handling descriptive metadata, and it is not recommended by IRT and myself.

2. Using DMS1 (Descriptive Metadata Scheme-1). As mentioned above, the hard part is how to map your metadata to DMS1. And there is not too much products on the market provide the use the full capability of editing DMS1.

3. Using private descriptive metadata. For example, put the metadata in an XML, register a private descriptive metadata scheme UL and a private key with SMPTE. When adding the XML to the MXF file, creates a static track, and its DMSegment, then links the KLV for your XML to the DMSegment. The problem of this way is that it is only for the internal use within an organization. When the file is given to another organization,, then the metadata becomes useless. 

Personally, I would chose the 3rd way for handling descriptive metadata in MXF files. An improvement I would suggest is to append the XML schema after the XML itself, so that it is easy to know what is in the XML, and also easy to map the XML in to a GUI to allow the user to edit the metadata.
posted @ 2010-11-06 00:46 Eric(MXF) 阅读(268) | 评论 (0)编辑 收藏

2010年11月5日 #

The customers want to concentrate on their own workflow, and leave the complexity of the MXF to the MXF software. So what the is requirement for the MXF software?

First, an MXF SDK is the infrastructure. It knows every thing in an MXF file.

Next, an MXF De-multiplexer (filter) which can parse an exising MXF file, generate a data structure in the memory which contains all the information of the MXF file, including structural metadata/descriptive metadata/dark metadata, index talbes, all the partitions, except the media essence. But it has the knowledge of what type of the essence the file has, where to get the essence for a given frame.

Then, an MXF Multiplexer (filter) which take the input essence, and generate the MXF file.

The De-multiplexer is easier compare to the Multiplexer, many companies in the market has the similar products. The only problem is that they don't support all the features that the customers need for their work flow. For example, the MainConcept has a De-multiplexer works beautifully with DV and MPEG2, but it doesn't support ANC/VBI track, AVC-Intra, and system item. So it only can be a good tool for demo purpose. 

The Multiplexer is the hard part, not too many available products on the market today. It needs a thoroughly understanding on MXF to generate valid MXF files.

If your workflow involves MXF, please put the requirement of your workflow here so that people can share the information.

-- usouthal@hotmail.com


posted @ 2010-11-05 00:33 Eric(MXF) 阅读(1292) | 评论 (1)编辑 收藏

仅列出标题