MXF : Operational Pattern : Les différents modèles de MXF

Les Operationals Patterns (OP) : les modèles des MXF

Sous ce terme barbare se cache un simple nom de code pour décrire le type de MXF que nous aurons à gérer : Tout comme chaque KLV va utiliser un modèle (ou template) pour ranger ses données, les MXF vont aussi utiliser et respecter un modèle parmi un panel de types disponibles qu'ils appellent "Operational Pattern"

Si vous voulez un exemple plus imagé, voyez cela comme des types d'arbre : Un arbre, c'est des racines, un tronc et des branches. Mais il existe plusieurs sortes d'arbres: des sapins, des chaînes, des cerisiers, etc... Chaque OP est un type d'arbre.

De base, il en existe neufs visibles appelés Generalized Operational Patterns :

Chaque case est un modèle d' Operational Pattern déjà prédéfini et normalisé : suivant le type de données et ce que vous voulez en faire, comment vous voulez lier les données entre elles, vous allez devoir faire un choix pour un modèle de MXF en particulier.

Chaque modèle de cette liste respecte des règles définies dans les docs SMPTE suivantes :

Le modèle d'Operational Pattern utilisé par le MXF DCP n'est pas l'un des 9 (1a à 3c) : il utilise le dernier de notre liste le "Specialized Pattern OP-Atom". 1

Fort heureusement, ce modèle est le plus simple : c'est un seul container avec un seul type de contenu. 2

Et en plus, il est de type Specialized Patterns, il y a donc des petites subtilités en plus, dont voici les principaux :

Concrètement, pour les images d'un film, chacune sera stockée dans une suite de KLVs séparés et uniques pour chaque image. Nous n'aurons pas une mixité d'essence 7. Par exemple, nous n'aurons pas un KLV pour une image, suivi d'un KLV pour le son. C'est pour cela que, dans un DCP, vous aurez plusieurs fichiers MXF. Chacun spécifique à un type d'essence (un MXF pour les images, un autre pour le son, un autre pour les sous-titres, etc)

Les autres Operationals Patterns sont plus complexes et en dehors de notre scope DCP : ils nous permettraient de faire des playlists (suite de contenu dans un MXF) ou même du montage (permet de faire démarrer ou arrêter un contenu à un endroit particulier même si nous avons tout le contenu dans le MXF).

Comment trouver le modèle Operational Pattern dans un MXF ?

Les Operational Pattern sont identifiés via un Universal Label spécifique (voir chapitre suivant pour la syntaxe).

L'Universal Label d'un Operational Pattern pourra être retrouvé dans les KLV suivants :

Nom du KLV UL du KLV
Partition Pack - Header 060e2b34.02050101.0d010201.01020400
Preface 060e2b34.02530101.0d010101.01012f00
Partition Pack - Body 060e2b34.02050101.0d010201.01030400
Partition Pack - Footer 060e2b34.02050101.0d010201.01040400

Pour les KLV de type Local Set (bébé KLV), nous aurons un Local Tag (clef sur 2 octets) spécifique pour l'Universal Label de notre Operational Pattern, et il sera 3B.09.

Exemple avec Preface (Local Set) :

╓─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── ║ 3C0A - Instance UID ║ 628ab1d4.a27d408d.804beb18.9b8a373f ║ 3B02 - Last Modified Date ║ 2020-04-20 16:33:52.0000+00:00 ║ 3B05 - Version ║ 258 ║ 3B07 - Object Model Version ║ 0 ║ 3B08 - Primary Package ║ 4a20501a.a942474f.83a9fdf2.2dec224c ║ 3B06 - Identifications ║ 1 item(s): 829e3a6f.dd75478e.8213a201.283538dd ║ 3B03 - Content Storage ║ 55679d5c.6c7c434d.96cbc1d3.99fb045c ║ 3B09 - Operational Pattern ║ 060e2b34.04010102.0d010201.10000000 (Operational Pattern - Specialized Pattern - OP Atom - SMPTE) ║ 3B0A - EssenceContainers ║ 2 item(s): 060e2b34.04010103.0d010301.027f0100, 060e2b34.04010107.0d010301.020c0100 ║ 3B0B - Descriptive Metadata (DM) Schemes ║ 0 item(s): ║ Resource [1] ║ SMPTE.ST.0377-1-2011 - MXF - File Format Specification - page 113 ║ Parser ║ klv ║ Data - Key ║ 060e2b34025301010d01010101012f00 ║ Data - Length ║ 0000be (190 bytes) ║ Data - Value [0] ║ 3c0a0010628ab1d4a27d408d804beb189b8a373f3b02000807e40414102134003b0500020102 ║ Data - Value [1] ║ 3b070004000000003b0800104a20501aa942474f83a9fdf22dec224c3b060018000000010000 ║ Data - Value [2] ║ 0010829e3a6fdd75478e8213a201283538dd3b03001055679d5c6c7c434d96cbc1d399fb045c ║ Data - Value [3] ║ 3b090010060e2b34040101020d010201100000003b0a00280000000200000010060e2b340401 ║ Data - Value [4] ║ 01030d010301027f0100060e2b34040101070d010301020c01003b0b00080000000000000000 ╙──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────

Il vous suffit de parser chaque item dans ces KLV et de trouver le bon Local Tag afin de récupérer l'Operational Pattern du MXF.

Les KLV Partition Pack sont des KLV Fixed-Data, il faudra trouver les informations au bon offset :

╓─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── ║ Major Version ║ 1 ║ Minor Version ║ 2 ║ KAGSize ║ 1 ║ ThisPartition ║ 0 ║ PreviousPartition ║ 0 ║ FooterPartition ║ 618286 ║ HeaderByteCount ║ 16244 ║ IndexByteCount ║ 0 ║ IndexSID ║ 0 ║ BodyOffset ║ 0 ║ BodySID ║ 0 ║ Operational Pattern ║ 060e2b34.04010102.0d010201.10000000 (Operational Pattern - Specialized Pattern - OP Atom - SMPTE) ║ EssenceContainers ║ 2 item(s): 060e2b34.04010103.0d010301.027f0100, 060e2b34.04010107.0d010301.020c0100 ║ Resource [1] ║ SMPTE.ST.0377-1-2011 - MXF - File Format Specification - page 41-44-46 ║ Parser ║ partition_pack ║ Data - Key ║ 060e2b34020501010d01020101020400 ║ Data - Length ║ 000078 (120 bytes) ║ Data - Value [0] ║ 0001000200000001000000000000000000000000000000000000000000096f2e000000000000 ║ Data - Value [1] ║ 3f74000000000000000000000000000000000000000000000000060e2b34040101020d010201 ║ Data - Value [2] ║ 100000000000000200000010060e2b34040101030d010301027f0100060e2b34040101070d01 ║ Data - Value [3] ║ 0301020c0100 ╙───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────

Comment identifier un type d'Operational Pattern à l'aide de son Universal Label ?

Pour un Operational Pattern OP-Atom - Specialized Pattern, son UL sera 060e2b34.04010102.0d010201.10000000

Vous pouvez tomber sur des MXF avec un OP UL 060e2b34.04010101.0d010201.10000000

La différence est sur le 8ème octet, c'est celui de la Version :

Si vous avez un Interop, les règles présentées dans cette documentation peuvent changer.
(un exemple, en Interop, le Partition Pack - Body peut ne pas exister)

Notes

  1. Réferences SMPTE 429-3-2007 - DCP - Sound And Pictures Track File : ↩

    • 1. Scope - This document is an Application Specification for D-Cinema applications. It is based on the SMPTE 390M OP-ATOM standard.

    • 4.1 General - D-Cinema Sound and Picture Track Files shall use the MXF file format [SMPTE 377M] in conjunction with the specialized Operation Pattern, OP-Atom [SMPTE 390M]. Unless otherwise specified, Track Files shall follow the normative provisions of SMPTE 377M, SMPTE 390M and SMPTE 379M (Generic Container) and their references, notably SMPTE 336M (KLV).

    • 3. Overview - A D-Cinema Sound and Picture Track File is an indexed, randomly-accessible MXF container for a single clip of a single essence track.

  2. Le concept de Single Essence Track peut être mal compris. Elle indique juste qu'il n'y aura qu'un type d'essence par MXF. Par exemple, que des images ou bien que des sons ou bien tout autre chose, mais jamais différents types dans un même MXF. D-Cinema Sound and Picture Track Files shall not contain interleaved, multiplexed, multi-scene or multi-format essence. -- SMPTE 429-3 - DCP - Sound And Pictures Track File ↩

  3. Les KLV métadonnées : 7.3.1 Minimum implementation recommendation : (...) 1 Preface Set, 1 or more Identification Sets, 1 Content Storage Set, and 1 Essence Container Data Set. (...) One Material Package including: the sets for the time code track. (...) The sets required for the Index Table (...) The Essence Descriptor required to describe the essence. -- SMPTE 390 - MXF - Specialized Operational Pattern OP-Atom (Simplified Representation of a Single Item) ↩

  4. Les Run-In sont des données présentes avant la Partition Header permettant d'avoir une synchronisation lors d'une lecture et utilisées dans des cas très précis. Nous ne rencontrerons jamais de Run-In dans un MXF de DCP. (Ref. SMPTE 377 - MXF Specifications — 6.5 Run-In Sequence) ↩

  5. La norme SMPTE pour le MXF permet d'avoir plusieurs Partition Body : ↩

    • 6.2.6 Body Partition - There shall be zero or more Body Partitions in an MXF file -- SMPTE 377-1-2009 - MXF - File Format Specification

    • Partition Kinds - Body Partitions : one or more partitions located in the file body. Multiple body partitions can be used to divide an essence container into a sequence of parts, provide for multiple essence containers or provide for multiple essence containers each of which are divided into a sequence of parts -- SMPTE 377-3-2013 - MXF Engineering Guideline

    Cependant, la norme SMPTE 429-3-2007 - DCP - Sound And Pictures Track File impose une seule partition Body : 4.3.5 Partitions - A Track File shall have three partitions: Header, Body and Footer. The closed and complete Header Metadata shall be carried in the Header Partition, the Essence Container shall be contained in the single Body Partition. et dans SMPTE 390-2011 - MXF - Specialized Operational Pattern OP-Atom 9. Recommended Partitioning of OP-Atom Files, le terme Body Partition est au singulier.

  6. Each Content Package of the Picture Track File's essence container shall contain one MXF GC Picture Item, each of which contains a single GC Picture Element. -- SMPTE 429-3 - DCP - Sound And Pictures Track File ↩

  7. Fondamentalement, le MXF peut supporter d'avoir cette mixité d'essences, vous pouvez avoir un KLV d'une frame, puis un KLV d'une partie de son, puis une autre frame et ainsi de suite. Mais dans notre cas, le MXF DCP type OP-1a, nous aurons qu'une continuité d'un même type d'essence (que des KLV JPEG2000 par exemple). ↩