Tc 06 Draft Outline 5 July 2011

Attached is the Draft outline of TC 06 as at 5 July 2011

AttachmentSize
Microsoft Office document icon TC 06 Draft Outline.doc32 KB

Dear all,

Last year at the IASA-2010 in Philadelphia, we have addressed the identification of the important topics that are of importance for Video while not for Audio. One of the important issue relates to the Wrappers!

It is clear that the wrapping of Audio with Video and ensuring the synchronisation of both aspects and the capacity of structuring and embedding or linking the metadata should be radically different for TC-06 than for TC-04.

As an illustration, the place of the MXF wrapper: two extreme approaches could be followed:
1. The MXF file includes everythings (the Carl Fleischhauer contribution to the IASA Journal N°37). In that case, the MXF declination is defined by a "Application profile".
2. The MXF file covers only the Audio-Video essence and a few identification and technical metadata (it corresponds to a unambiguous and broadly implemented standard MXF-OP1A). In that case, the structures and the metadata are expressed independently, the whole being bind by a higher level wrapper (such as METS). It is clear that in that case other wrappers could be applied in place of or in parrallel with the MXF-OP1A, such as the QuickTime, the AVI, the DVB-Transport stream and mix such as JPEG2000 and MPEG-4 / H264.
Within the Library of Congress, the two approaches have been followed: for example, the first for the "Culpeper media Center archiving project" and the second for the "Public TV Broadcast archiving project". Each approaches have their advantages and drawbacks The first appoach is fitting for large and stable projects; the second is fitting when flexibility and simplicity is requested.
In consequence, I recommend that the draft "Table of Content" of TC-06 as proposed by Kevin should be revised with a specific chapter on the "Wrapping" recommendations and issues and with subsequent adaptations of the other chapters, in particular the introduction of cases for the metadata and the structures.

Best to all,
Guy Maréchal

I agree that we should consider alternatives to having everything needed (for exchange, for preservation) inside one wrapper file. The issue could be restated as "wrappers or containers". There are more types of wrapper and container than listed above, including AXF and the Japanese proposal (that also recommends LTFS) that was presented in a poster at FIAT/IFTA in 2010. The BBC is making a summary of all this. Thomas Heritage is pulling information together now, and I hope that by the end of August we'll at least have a BBC draft summary of the various options.

Thanks Richard!

I have had the opportunity of analysing in detail the AXF proposal! From technical point of view it is a convincing solution to many existing interoperability and persistence problems. I discussed it longly with Brain Campanotti (who is in charge at Front Porch Digital of promoting AXF): despite many efforts and although on many aspects AXF solves many unsolved problems of MXF, I understand that the SMPTE is reluctant in envisaging of entering in a process where there is a risk that AXF would compete with MXF. At my point of view, MXF and AXF could remain complementary: that is illustrated in the proprietary offer of Front Porch Digital: DIVArchive V7.0
Content Storage Management (CSM) solution.
In consequence, for the time being, the detailed specifications of AXF remain under embargo and the Front Porch Digital implementation is 'in fact' now still proprietary. The intention is cleary announced "OPEN" but ...
For more details see www.OpenAXF.org. Another interesting subject is related to the LTFS SMPTE effort, which at many aspects is also complementary with the AXF.
I have only followed a short presentation of the Japanese proposal. Apparently it does not solve the platform & size independence (what AXF does): it seems that it is the reason why they recommend the LTFS.
I look forward receiving copy of Thomas Heritage report.

Guy Maréchal