MXF : Picture : RGBA Essence Descriptor

Préface

Le KLV RGBA Picture Essence Descriptor est un sous-élément du type Generic Picture Essence Descriptor :

• Les deux éléments sont définis dans SMPTE 377-1-2011 - MXF - File Format Specification.
• Son Universal Label est 060e2b34.02530101.0d010101.01012900

Les métadonnées

Voici un rendu d'exemple :

╓───────────────────────────────────────────────────────────────────────────────────
║   3C0A - Instance ID               ║  2cb46505.be6b41c3.abbe8848.d06e21c9
║   FFFF - SubDescriptors            ║  1 item(s) : 6054268f.8fdf47ba.98db7167.5d3f704b
║   3006 - Linked Track ID           ║  2
║   3001 - Sample Rate               ║  24/1
║   3002 - Container Duration        ║  1
║   3004 - Essence Container         ║  060e2b34.04010107.0d010301.020c0100 (JPEG2000 Picture Element - Frame Wrapped)
║   320C - Frame Layout              ║  FULL_FRAME (0)
║   3203 - Stored Width              ║  4096
║   3202 - Stored Height             ║  2160
║   320E - Aspect Ratio              ║  4096/2160 (1.90)
║   3201 - Picture Essence Coding    ║  JPEG 2000 4K Digital Cinema Profile (060e2b34040101090401020203010104)
║   3406 - Component Max Ref         ║  4095
║   3407 - Component Min Ref         ║  0
║   320D - Video Line Map            ║  2 item(s): 00000000, 00000000
║   3401 - PixelLayout               ║  8 item(s): 
║                                    ║  - X' - DCDM X color component (SMPTE 428-1 X’) - 12 bytes
║                                    ║  - Y' - DCDM Y color component (SMPTE 428-1 Y’) - 12 bytes
║                                    ║  - Z' - DCDM Z color component (SMPTE 428-1 Z’) - 12 bytes
║                                    ║  - Termination - 0 bytes
║                                    ║  - Termination - 0 bytes
║                                    ║  - Termination - 0 bytes
║                                    ║  - Termination - 0 bytes                                    
║                                    ║ -  Termination - 0 bytes
╙───────────────────────────────────────────────────────────────────────────────────

SubDescriptors fait référence au KLV JPEG2000 Picture Sub-Descriptor (ci-dessous)

PixelLayout va décrire comment sont stockés les pixels et leurs formats. Dans notre cas, nous aurons toujours un X'Y'Z' en 12 bits. Si l'encodeur n'a pas pu déterminer la valeur de PixelLayout, il va mettre des 0 partout.

Essence Container indique le type de container pour l'essence avec son Universal Label :

Il existe d'autres type de container, pour notre cas (JPEG2000), notre UL sera celui de JPEG2000 Picture Element

Frame Layout va déterminer si c'est du progressif ou de l'entrelacé (en gros), il y a plusieurs codes :

On sera toujours sur du Full Frame.

Stored vs Sampled vs Display sont 3 possibilités de gestion et d'affichage de l'image.

• Stored va indiquer la taille de l'image stockée, avec toutes les informations possibles, même qui ne devraient pas être projetés.
• Sampled va inclure l'image et les données auxiliaires (même métadonnées)
• Display est l'image qui va être affichée sur l'écran et juste l'image en supprimant tout le reste qui pourrait parasiter la projection.

Dans un MXF DCP, toutes les items Sampled et Display seront absents : seules seront définies Stored qui correspondront donc aux valeurs utilisées pour l'affichage à l'écran.

Voici un récapitulatif entre Stored, Sampled, Display et les différents Offset :

Component Max Ref est la valeur maximale qu'on pourra avoir dans l'encodage RGB. Ici, nous aurons toujours 4095 car 12 bits et que 2¹² = 4096). Mais alors pourquoi 4095 et pas 4096: parce qu'on compte à partir de 0 donc il y aura 4096 valeurs allant de 0 à 4095 :)

Component Min Ref est la valeur minimale pour l'encodage RGB. Pour nous, nous partirons toujours de 0.

Linked Track ID est le Track ID défini dans l'une des Track du Package (ici Source Package) qui est défini dans le Descriptor de ce dernier :

Rapidement pour les éléments comme DisplayF2Offset et StoredF2Offset : vous ne les trouverez jamais dans un MXF DCP car lorsque le FrameLayout est à FULL_FRAME, ces éléments n'ont aucun intêret et ne doivent donc pas être présent.

Picture Essence Coding est un identifiant Universal Label permettant d'identifier le type d'encodage et/ou de compression de l'essence :

Selon le type de contenu (2K ou 4K), vous aurez l'un ou l'autre. Le dernier est à utiliser sur du JPEG2000 pas encore normé (du 8K ? :) Vous en trouverez d'autres dans ce fichier.

Video Line Map indique la première ligne active de chaque champ de l'image. Sa valeur par défaut sera 0. Cet item est surtout utile quand le FrameLayout est différent de FULL_FRAME, c'est-à-dire si vous avez des images entrelacées. Vu que nous sommes en progressif, vous aurez (normalement) toujours 0. (il m'est arrivé de découvrir dans certains MXF produits et diffusés une valeur à (2, 4) avec pourtant un FrameLayout en FULL_FRAME)

Déterminer pourquoi Video Line Map et PixelLayout peuvent être absents alors considérer comme obligatoire même avec des valeurs à 0

Structures des données

Voici la structure complète d'un RGBA Essence Descriptor, énormément d'items sont peu ou pas utilisés dans un MXF DCP :

Les éléments en gris ne sont pas utilisés la plupart du temps mais ils peuvent l'être dans certains contextes. N'oubliez pas que un RGBA Essence Descriptor dépend d'une hiérarchie de type, il y aura donc énormément d'éléments utiles pour d'autres utilisations de MXF (pas forcément que pour un DCP), il est donc normal d'avoir des pans entiers d'items en gris.

Le document faisant référence sera SMPTE 429-4 - DCP - MXF JPEG2000 Application qui va donner toutes les items et leurs valeurs par défaut.

Notez que certains éléments considérés comme Best Effort (donc requis) peuvent ne pas exister. Ne me demandez pas pourquoi : pourtant, la norme les impose mais sur énormément de MXF DCP, des éléments - comme Video Line Map ou PixelLayout par exemple - peuvent ne pas être présents.

Pour le type RGBALayout de l'item PixelLayout, c'est un encodage spécifique, c'est 8 éléments de 2 octets chacun. Pour chaque élément, le premier octet est un code qui va donner le type (exemple R, G, B, X, Y, Z, etc...) et le second octet la DepthColor. Si c'est entre 1 à 32, ça sera juste de 1 à 32 octets :) - sinon si le code est :

• 253 : un DepthColor HALF - Floating Point 16 bits
• 254 : un DepthColor IEEE - Floating Point 32 bits
• 255 : un DepthColor IEEE - Floating Point 64 bits

Dans nos MXF DCP, nous n'aurons que des codes 0xD8, 0xD9 et 0xDA qui réprésente un X', Y', Z' (voir chapitre XYZ)

Pour le premier octet, voici la liste des codes (les 3/4, c'est un simple code ASCII, sauf qu'ils ont rajouté d'autres éléments qui ne le sont pas) :

Note: Dans la norme SMPTE 429-4 - MXF JPEG2000 Application, il est indiqué qu'un item Gamma existe, cependant il n'existe aucune référence dans la norme SMPTE 377-1 (MXF - File Format Specification). Il se peut que l'item désigné par Gamma se cache peut-être derrière l'item Color Primaries, ou Coding Equations ou bien Transfer Characteristic. Cependant, sur l'analyse de plusieurs MXF DCP, je n'ai constaté aucun de ces items.

Hiérarchie du format

Interchange Object → Generic Descriptor → File Descriptor → Generic Picture Essence Descriptor → RGBA Picture Essence Descriptor

Code : Lire ce KLV

Code source pour lire les headers :

import sys
import io

# Conversion en int
def to_int(length : bytes = b'') -> int:
    return int.from_bytes(length, byteorder='big')

if len(sys.argv) < 2:
    print("Usage: %s <mxf>" % sys.argv[0])
    sys.exit(1)

mxf_file = sys.argv[1]

with open(mxf_file, "rb") as file:

    while True:

        # Key : Universal Label
        key = file.read(16)

        # End of file
        if not key: 
            break

        # Length (BER format)
        length = to_int(file.read(4)[1:])  # BER format - read last 3 bytes

        # Value
        value = file.read(length)

        # Filter by KLV : RGBA Essence Descriptor
        if key.hex() != "060e2b34025301010d01010101012900":
           continue

        # Show each KLV
        print("{key} - {length:>6d} bytes - {value}...".format(
            key    = key.hex(),
            length = length,
            value  = value[0:16].hex()
        ))

        # read each item
        data = io.BytesIO(value)

        # "item" is a baby KLV:
        #  localtag (key)  :  2 bytes
        #  item length     :  2 bytes (no BER format)
        #  item value      :  variable bytes

        while True:

            # get local tag (2 bytes)
            localtag = data.read(2)

            if not localtag:
                break

            # get item length (2 bytes, directly int, NOT Ber format)
            item_length = to_int(data.read(2))

            # get item value
            item_value = data.read(item_length)

            # Show each item
            print("{localtag} : {item_length:>2d} : {item_value}".format(
                localtag    = localtag.hex(),
                item_length = item_length,
                item_value  = item_value.hex()
            ))

Voici son exécution sur le MXF 2D.mxf :

$ ./mxf-klv-picture-rgba-essence-descriptor.py "2D.mxf"

# KLV RGBA Essence Descriptor
060e2b34025301010d01010101012900 -    189 bytes - 3c0a00102cb46505be6b41c3abbe8848...
3c0a : 16 : 2cb46505be6b41c3abbe8848d06e21c9
ffff : 24 : 00000001000000106054268f8fdf47ba98db71675d3f704b
3006 :  4 : 00000002
3001 :  8 : 0000001800000001
3002 :  8 : 0000000000000001
3004 : 16 : 060e2b34040101070d010301020c0100
320c :  1 : 00
3203 :  4 : 00001000
3202 :  4 : 00000870
320e :  8 : 0000100000000870
3201 : 16 : 060e2b34040101090401020203010104
3406 :  4 : 00000fff
3407 :  4 : 00000000
3401 : 16 : 00000000000000000000000000000000

DUPLICATE JPEG2000 Picture SubDescriptor

On voit qu'avec quelques lignes, on récupère l'ensemble des informations brutes :

• Colonne 1 : le Local Tag - la clef spécifiant le type de valeur (comme pour la Key d'un KLV)
• Colonne 2 : la taille en octets de sa value.
• Colonne 3 : la valeur brute, sans aucune conversion.

Vous devrez maintenant convertir chaque valeur brute dans un format qui lui est propre. Et pour cela, il faudra vous baser sur le Local Tag en colonne 1.

Notez que pour les Local Tag, vous devrez lire le KLV Primer Pack afin de faire correspondre chaque Local Tag avec sa véritable désignation (Universal Label, Type, Taille de chaque sous-élément, Formatage, ..). Plus d'informations dans le chapitre Local Tag.

Même sans convertir, nous pouvons déjà identifier quelques éléments, comme des Universal Label.

Prenons un exemple, le 320E a une taille de 8 octets. Si on regarde sa désignation, c'est un Local Tag Statique représentant un Aspect Ratio et de type "rational", cela veut dire de format "num/num". La valeur de 8 octets (0000100000000870) doit être séparé en deux: 2 x 4 octets : 00001000 et 00000870. Les deux valeurs convertient, nous avons 4096 et 2160. Nous aurons donc un "4096/2160" qui correspond à l'Aspect Ratio de notre film (1.90 arrondi).

Vous devrez donc, pour chaque valeur, faire correspondre son type et son formatage. En lisant chaque docs SMPTE, on découvre ces petits pokemons d'informations. Fort heureusement, une partie est compilée dans le chapitre Local Tag ou bien dans mxf-analyzer.

La suite...

Le KLV supplémentaire est le JPEG2000 Picture Sub-Descriptor

Notes