The MXF Mastering Format A proposal to address existing MXF interoperability issues.

1. The MXF Mastering FormatA proposal to address existing MXF interoperability issues. Clyde Smith, Steve Fish, Bruce Devlin, et al.

2. Turner Entertainment Networks 8 Feeds • East Coast • West Coast • TNT in HD • Brazil • Argentina • Mexico • Venezuela • Pan Regional • Pan European • Germany • Sky • Africa • Pan Asia 13 Feeds • TCM Domestic • TCM Canada • TCM Latin America • LA Pan Regional • France • Spain • UK • Nordic 5 Feeds • Super Station East • Super Station West • WTBS -17 • WTBS-DTV • WTBS Canada • U.S. East Coast • U.S. West Coast 24 Feeds • U.S. East Coast • U.S. West Coast • Brazil • Argentina • Mexico • LA Pan Regional • U.K. • Nordic • Denmark • France • Germany • Pan European • Spain • Italy • Poland • Romania • Hungary • Pan Asia • Australia • Taiwan • Philippines • Korea • India • Pakistan 11 Feeds • United States • Brazil • LA Pan Regional • UK • France • Germany • Spain • Italy • Pan European • South Asia • Pan Asia • India • Italy • UK Serving North America from Atlanta, South America from Buenos Aires, EMEA from London and Asia/Pacific from Hong Kong • NBA-TV Domestic • NBA-TV International • NBA-TV HD

3. Turner Entertainment Networks Distribution Creation and Acquisition Cable Operators Branded Channels SVOD VOD PPV “Playout” Operations Warner Brothers Technical Operations Repurposing Requires Reprocessing Satellite Operators Branded Channels PPV Turner Studios and Original Productions Turner Broadcasting System Entertainment Operations New Media Interactive On Line Broadband Mobile Phones Games Other Program Providers Retail Sales VHS DVD Licensed Merchandise

4. Operational Strategy Locating key network support functions within their respective markets is a strategy that we’ve employed successfully in London, Hong Kong and Buenos Aires. Our international operations tend to be lean, which makes their staffs highly collaborative. The marketplace dynamics are changing so we must be innovative More and more “TV” content moving online means more choice for consumers and more opportunity for advertisers to reach highly targeted, highly desirable audiences. GameTap, CNN Pipeline, Dramavision, VeryFunnyAds.com, PGATour.com, ACCSelect.comand Toonami Jetstream offer broadband users a mix of familiar and new.

5. Workflow Key Enablers • I.T. based facilities • Automated Repurposing and Reprocessing • Standardized protocols and formats • MXF and AAF • BUT are they ready for implementation in our operations?

6. We all know • Building facilities based on IT workflows saves money and speeds up time to market of products! • But…. To succeed you need standards for interoperability • If vendors are using their own “optimised” yet different wrapper formats: Program Stream, VOB, Transport Stream, DV, AVI, Quicktime, MP4, TARGA, MXF OP1a, MXF OP1a (Sony), MXF P2, OMF, TIFF, etc. • And…If many users have their own specific implementation options as well

7. We all know • Then eventually all users will pay all the vendors to implement all the formats and all the options to achieve interoperability

8. The problem – make multiple versions cheaply

9. MXF • Was created to deliver business value to the industry • Q: So what’s missing? Why can’t we find a solution off the shelf? • A: Too many MXF tools MXF has many options to address to many problems

10. Principle Developers and Supporters of the MXF Mastering Format

11. The Goals • Data entry. Data should be entered once at the appropriate point in the asset life cycle. This data should be available to any system looking at that asset. • Data updates. There should be the ability to revise or edit data. Any revisions or edits must be updated across the ‘Inventory’ • Files usable before being closed (i.e. partitioned.) This allows preview work to start before the write cycle is completed and the file closed. The time between first byte arriving and first use should be reasonable short. • The concept of an asset ‘Inventory’. This is where everything related to a single asset is stored. Asset in this context means a single episode of a show. • The ability to extract a copy of this ‘Inventory’ and be able to send it to an independent site. Once received, it must be importable to the asset management system (which may be different to the source system), based solely on the supplied file. This means it must be self describing with all essence and metadata bound in. One benefit of this is that best of breed local solutions can be employed and reduce reliance on single monolithic systems across organisations.

12. The Goals • Storage system independent. As assets are expected to be used in many different places at different times there must be no reliance or limit on particular physical storage devices or systems. • Flexible restores. A need was identified for ‘Partial Restore’. This is where a selection of essence tracks from the inventory would be restored to form a new version of the asset. This functionality would be further extended to give ‘Partial Partial Restore’ where a time sliced selection of essence tracks would be restored. Finally, a ‘Partial Partial Partial Restore’ requirement was identified where a group of time sliced sections of a selection of essence tracks would be restored, this last requirement was particularly aimed at clip selection for edit purposes. • Flexible stores. The need to add tracks (essence or metadata) to an ‘Inventory’ without the overhead of having to re-write the entire ‘Inventory’. • Metadata must reside with, and be updated throughout an assets lifecycle. • Essence files to be external. As flexibility of adding (and removing!) of essence was required it was realised that for this to be most efficient all essence tracks should be external.

13. The Goals • Files must represent Multiple versions • Different numbers of breaks in a program • Different language variants • Different titles & credits • Different output deliverables from one master • Using MXF must lead to efficiency improvements • Reduction in transfer bandwidths • Reduction in storage requirements • Increased automation • Partial restore direct from tape • Standardised version identification • Greater workflow choices • Risk reduction for the end user • Choice of multiple vendors working to a common standard

14. Defining the problem • Put all functional blocks on a diagram, label them and link them at a physical / networking level. • For each major workflow create a table that shows the individual actions required in that workflow. Each action should be documented to describe what happens at the physical, essence and data levels. • Convert each action into a UML activity diagram that shows in sufficient detail what is required from the action, and the messages that are likely to flow. • Look at the lifecycle of material

15. Defining the problem • Look at the lifecycle of material

16. Defining the problem • Work through some material lifecycle examples • Identify processes • Identify common states • Identify properties of file which reduce complexity • Identify properties of file which improve operational flexibility • Example…

18. Defining the problem • Identify all the interfaces clearly – an example • Src ID - 8 • Dst ID - 15 • Level - a • Worflow ref - 8.15.a • Description - move from Ingest to playout • Type - Data & Essence • Req. mech - automation • Metadata src - file • Metadata dst - file • Schema - n/a • Essence src - ingest station • Essence dst - on-line server • Notes - FTP based move of MXF wrapped data

19. Defining the problem • Identify all the interfaces clearly • Src ID - ID of the source of the data • Dst ID - ID of the destination of the data • Level - sub ID to distinguish which workflow is in use • Worflow ref - unique ID of this workflow step • Description - textual description of workflow step • Type - Data / essence / physical / control / SDI • Req. mech - A Trigger e.g. API, hot folder, keyboard, automation • Metadata src - e.g. Business DB, Asset DB, DAM, Automation, file • Metadata dst - e.g. Business DB, Asset DB, DAM, Automation, file • Schema - schema for metadata if available • Essence src - which machine • Essence dst - which machine • Notes - anything else • Results in a very big table

20. Parameterizing the specification

21. Document results… • What do the files look like? • List the different physical requirements of the file • List the metadata requirements of the file • Initially document them as a proprietary format • Categorise requirements • Those that are generally applicable – RPzzz recommendation • Those that are business specific – AS-TBS

22. The Specifics • Refer to files by their function not their OP • Programme Components • Simple Programme Versions • Complex Programme Versions • Programme Inventories

23. Components,Versions and Inventories ‘Components’ are single essence or data tracks e.g. a Video track, Audio track or Metadata track. ‘Versions’ are pointers to Components and describe how a collection of Components may be played. There can be many different Versions pointing to the same Components. ‘Inventories’ are a repository for all the Versions and Components for a single asset. There should be no duplication of Components within the Inventory. There maybe many similar Components of the same type, for instance there could be three different Videos – High Resolution edit master, Transmission master and a Browse resolution copy. At least three versions would exist to allow each to be played.

24. Example of Components Programme Components Video Programme Components Audio Programme Components Audio Programme Components

25. Principal – versions link to essence Inventory Simple Programme Version

26. File Structure Examples Inventory A Simple Programme Version within the Inventory

27. Inventories, Components and Versions These definitions can be loosely related to Operating Patterns in the following way: Components OP1a. Versions OP2B or OP3B depending on how complex the program structure is. Inventories could OP3B or OP3C depending on how many versions are in the Inventory. This shows that talking in ‘OPs’ is variable and also that all Operating Patterns are likely to be met in a complex system.

28. example_vbi0.mxf (SMPTE436M) Example – adding a subtitle Simple Programme Version

29. Different title/credits A Complex Programme Version within the Inventory

30. Inventory eng Complex Programme Version within the Inventory fre Complex Programme Version within the Inventory Different title/credits

31. Metadata Example RFC 4646(ISO 639 ++) Audio track Metadata track Annotation Language en-US Spoken Language en-GB Full Spoken language en-GB-x-DolbyE-a-PostWatershed Description Dolby E surround track with profanity RFC 4646(ISO 639 ++) Data track Metadata track Annotation Language en-US Spoken Language gr-Grek Full Annotation gr-Grek Description Greek subtitling for use in Greece

32. Process Benefit example Archive Central Storage Add “fre” audio track Playout Server Broadcast Rewrite tape to archive new version Copy back entire file Interleaved files component files Archive Central Storage Add “fre” audio track Playout Server Broadcast Append “fre” audio to archive new version Copy back just the“fre” audio track

33. Format Specifics Basic structure of the MXF Master format includes: • Single-essence Programme Component files • OP1a files that enable Read While Write & random access • Programme Version files that reference Components • Simple Programme Versions for playout servers • Complex Programme Versions for editing and version management • Programme Inventories that collate multiple versions • An Inventory contains all the versions of an asset • Controlled Descriptive metadata • DM Tracks used to identify the language of an audio component • Controlled way to specify the system • Paramaterizing the Specification for a local facility is done in a consistent way for vendors – enhancing interoperability

34. Process Analysis • If the underlying file format isstandardised & pervasive • Standardised Analysis tools canbe used to… • model workflows • define interfaces between departments • create service oriented software interfaces • define, track & model interactions between departments • define, track & model active, passive & redundant operations

35. MXF • Needs to be constrained in order to deliver its value. • Q: How can this value be delivered for you? What needs to be done to MXF in general? • A: Accurate problem specificationand a Recommended practise to constrain range of options in the MXF toolbox

36. OP1a Interleaved Lengthy tape rewrites Bandwidth hogging file transfers Incompatible proprietary formats MXF Master Format Simple to repurpose files Built-in Metadata Storage Highly Interoperable Formats Comparison

37. Standardisation • SMPTE • Many are keen to see this work in committee • RDD option fast but is simply a static “we did this” document • EG option lacks enforcement • RP option feels right • Full standard wanted by some • We would welcome your review and comments As well as your support

38. MXF API Overview • In order to promote digital interoperability, and the exchange of program material using files Turner is promoting a standardisation of the use of MXF in the broadcast production and playout industry. • As part of the standardisation is a requirement not only to specify exact MXF operating patterns to be used but also how they will be manipulated. • Efforts are underway to develop a common MXF Processor API • This API is intended as a universal language for the manipulation of MXF media objects.

39. A Standardized API for MXF manipulations • With a standard file format • Many operations become standardized • Restore • Partial restore (of a subclip) • Partial restore (of a subset of tracks within a subclip) • MXF version files • Can be represented in MXF • Are small in size • Fully describe the source file • Can fully specify a destination file • Are web services friendly

40. Why? • Vendors currently develop their own proprietary APIs • These restrict interoperability and thus automation (or control) systems must implement many different APIs • Since we’re trying to recommend an MXF standard let’s do the same for the API

41. Benefit • A single open API that automation (or controller) can interface to • Vendors interface to a common API • Reduces integration costs and time • Provides interoperability at a control layer for MXF aware devices

42. More than an API • An open API that each vendor interfaces to • Each toolkit vendor will support the API and will provide a subset (or maybe all) of the transformations/functionality • The calling application (automation) may issue a query to see which of the underlying processors can support a particular function • This approach will allow multiple vendors to collectively provide the overall system functionality.

43. More than an API • Proposed that the API runs under SOAP • In general set up as a Call / Response system with a ticket or handle to the job in progress • allowable exception to this is when the job terminates and the processor wants to flag the calling system so it doesn’t have to persist the result set • Management of name space • Referential integrity

44. Basic Functionality • Create a media object • Append to that object • Move a whole object • Copy a whole object • Delete a component from within that object • Extract one or more components from an object • Delete a whole object • Interrogate an object • Manage the activities

45. Use cases • Complex Program Version to Simple Program Version • Simple Program Version to Complex Program Version • Create/remove empty Program Inventory • Add/delete Complex Program Version to Inventory • Add/delete Program Component to/from Program Inventory • Add/delete Program Component to/from Complex Program Version • Complex Program Version to Complex Program Version

46. Referential Integrity • This is a set of rules not a set of functions within the API • Only packages actually handled by the processor, or appearing in a configured directory will be managed by the referential integrity checking. • Ensures the header and associated essence files are valid

47. Name Space? • Should the processor embody & enforce a naming convention for component and version files? If so is this naming convention part of the MXF application specification? • Should this name space be determined solely by the end user, or should a recommended practice be developed to try to encourage standardisation?

48. Summary • MXF Processor API will provide a common set of functions that all MXF compatible devices will support • Advantage that a given device will require minimal testing/development for integration into environment supporting API • Allow customers/users to quickly determine if a device should be compatible within their environment • Reduce overall system integration time (and cost) for new device • Vendors will have immediate solutions their device can integrate within should they adopt open API

49. We Are Here Repurpose Many Master Once

50. NAB 2007 • Tuesday 1p-5p MXF Papers in Broadcast Engineering Conference Reception (Immediately Following - Free Drinks!) • Demonstrations Area • files ready now or being developed • Snell & Wilcox • Omneon • Marquis • Softel • API & metadata interop being defined • Metaglue • TMD • Opencube • Pro-bel