El documento describe brevemente el formato Material eXchange Format (MXF), explicando que surgió para normalizar la metadata de los videos más allá del código de tiempo. Explica que MXF define cómo transportar datos auxiliares de forma versátil a través de todas las etapas sin comprometer la eficiencia. Finalmente, resume algunas características clave como su estructura basada en paquetes KLV y particiones, así como su objetivo de maximizar la flexibilidad.

1. the Material eXchange Format
MXF
Breve Descripción
Gonzalo Rielo

2. La necesidad
En el momento de aparición del MXF, el
escenario era una mezcla de formatos de
vídeo, cintas, documentos de Word,
Excel, post-it, notas y hojas en las cintas.
La única metadata que estaba
normalizada para la vida completa del
vídeo era el Código de Tiempo.
Sin embargo el TC no es limpio muchas
veces existiendo saltos y perdidas lo que
penaliza la producción.
Se regenera para solucionarlo.

3. Instalación basada en Almacenamiento

4. Streaming vs. Transferencia de Ficheros
• Streaming • Transferencia de Fichero
– N x Tiempo Real – Asíncrona
– multicast / broadcast – point to point
– look & listen en la – Sin monitorización de A/V
transferencia – Mode Pull
– Modo push – acknowledged
– Sin necsidad de – Se asume que es sin errores
acknowledged – Con mecanismos de reenvío y
– Errores de canal insalvables recuperación
– Error Correction coding – Inicio y fnal conocidas
– Sin incio y final – Se accede de modo aleatorio
predetermindado
– Los dispositivos acceden de
modo secuencial

5. Orígenes y Wrappers
• Convergencia de Tecnologías
• Búsqueda de un estándar de intercambio y formato
• Necesidad de Wrappers y datos con el mismo
peso que el resto de esencias
• Ficheros maestros
– Crear ficheros maestros a nivel de MXF inferiores
– Con esto se pueden utilizar ficheros finales para la
emisión y otros a otros propósitos.
• Ficheros de esencia que contengan audio, vídeo y
datos y puedan ser referenciados desde el maestro

6. Qué es MXF
• Fichero abierto
• No es un códec
• Define cómo llevar los datos auxiliares
• Versátil
– EDLs, Playlist
– Streaming
– Entronos Edit while Ingest
• Diseñado para maximizar la flexibilidad sin
compromiso de la eficacia transportando la
maetadata en todas las etapas
• No es un formato de masterización (authoring)

7. Formato
• Se puede entender como una colección de
Paquetes consecutivos:
– File Package: es la fuente del material
– Material Package: se puede entender como una
salida de un timeline.
• Identificando los medios de esencia
• Inserción de metadata

8. Formato
• Sobre la estructura de paquetes se define el
formato de los ficheros MXF.
• La estructura mínima contiene un File Header
y un File Footer. El file body es opcional.

9. KLV
• K = Key: Identificador único de 16 bits
• L = Length: Definición de la longitud del paquete
•V = Value: Datos
K L K L K L K L
Partition Picture Sound
Hdr. set
Hdr. set
Hdr. set
Hdr. set
K L Pack K L K L K L K L K L K L Element K L
fill
Element
“played” Picture
Material Package Track
“played” Sound
Track
Stored Picture Track
File Package Stored Sound Track
Con esta estructura se pueden obviar los paquetes erróneos o no
conocidos sin parar la reproducción

10. KLV, Datos de Grupo
No todos los datos en MXF tienen su propio
paquete KLV, sino que los hay que pueden
estar empaquetados conjuntamente.
•Local Sets se utilizan
para empaquetar la
Metadata
•Defined Length
packs se utilizan para
las tablas índice y los
Partition Packs

11. KLV, Contenedores de esencia
Diferencia entre frame wrapping y file wrapping
Sólo los Frame Wrapping permiten hacer streaming sino se
traduce en buffering en la reproducción

12. Andamiaje
• Essence Containers – Modo bien definido de transportar
los datos (MPEG, DV,...)
• Index Tables – Tablas que permiten componer offsets de
tiempo en offsets medidos en bytes. Permite la
localización de los datos.
• Header Metadata – Descripción técnica de la estructura
y contenidos del fichero más metadata opcional. Tiene
Metadata Estructural y Descriptiva
• Partition Metadata – La metadata usada para describir la
estructura física del fichero.
• Random Index Pack – Índice creado para la
localización de las particiones en un fichero.
• Run-In – Bloque opcional y no estándar utilizado en
patrones especializados (op Atom)

13. Tabla Índice
• Permite acceso aleatorio a los ficheros.
• Son un mapa numerado de los frames con un byte de
offset dedicado por el tipo de formato.
• Para ello define las variable CBR (constant bit Rate)
VBR (Variable Bit Rate) + Offset

14. Tabla Índice

15. Particiones
Por qué:
•El hecho de tener que repetir la tabal índice es un de las razones
para dividir en partes el MXf.
•Donde el codificador decida crea la partición, escribe el
índice del segmento y continúa con la esencia
• Para poder multiplexar distintas esencias de modo conjunto.
•Entrelazado
•Transporte multiplexado

16. Particiones. Reglas de Inserción
1. Tiene que existir un Header y un footer Partiton
Pack. Los Body y Zero Partition Pack son
opcionales.
2. Una prtción siempre empieza por un un Partition
Pack que contiene un valor que lo identifica como
de tipo Header, Body o footer. A continuación
tiene información sobre el MXF, OP, tipo de
esencia, dónde está la tabal índice...
3. El Partition Pack va seguido de un Header
Metadata que es obligatorio tanto Header, Body y
Footer Partition. Esto permite un acceso aleatorio
a los datos en cualquier situación. Además
permite actualizar la metadata en los
reproductores

17. Particiones. Reglas de Inserción
Header Partition
Open Header Open Header
Run Header Index Essence Next Partition
Partition
In Partition Pack Metadata Table Container Pack
(optional) (optional) (optional)
Header Partition
Closed Header Run Closed Header Header Index Essence Next Partition
Partition In Partition Pack Metadata Table Container Pack
(optional) (optional) (optional)
Body Partition
Body Partition Body Partition Header Index Essence Next Partition
Pack Metadata Table Container Pack
(optional) (optional) (optional)
Footer Partition
Footer Footer Partition Header Index Random
Partition Pack Metadata Table Index Pack
(optional) (optional) (optional)
El Run-In se utiliza en estructuras especiales y el RIP (Random Index Pack se un
índice de particiones para mejorar los accesos aleatorios

18. Particiones. Reglas de Inserción
5. Cada contenedor de esencia lleva un
identificador único “BodySID” y cada esencia
puede ser distribuido por más de una partición
6. Cada Header o Body Partition tendrá
información de un solo tipo de esencia.
7. Todos las particiones que contengan la misma
esencia tendrán el mismo BodySID.
8. El orden de los datos divididos en particiones
tiene que ser el mismo que la esencia sin dividir.
9. Cualquier contenedor de esencia tiene que llevar
una tabla índice con un identificador único por
fichero llamado “indexSID”.

19. Relación BodySID e Index SID
I. Si una Partición ha embebido un contenedor de
esencia con un BodySID dado, sólo son
permitidos los segmentos de Tabla Índice en esa
partición, aquellos lincados con el valor de
IndexSID lincaje. El IndexSID es por tanto
único con cada BodySID.
II. Si no hay contenedor de esencia en una
partición, entonces todos los segmentos de la
tabla índice de un IndexSID dado pueden
incluirse en la partición.S
III. i no no hay segmentos de Tabla Índice en una
partición, se pude ponoer un contenedor de
esencia único con un único BodySID.

20. Tipos de Particiones
Particiones con una esencia
Particiones con varias esencias

21. Resumen de las Reglas de Inserción
 Contenedores de Esencia
1. Un File Body pueden tener una o más contenedores de Esencias
2. Cada Contenedor de Esencia se identifica con un único
BodySID.
3. El Contenedor de Esencia puede ser distribuidos en uno o más
particiones.
4. Las particiones de los contenedores de Esencias estarán
secuenciales en el fichero físico aunque no necesariamente en
particiones adyacentes
5. Cada partición identifica su Contendor de Esencia con el valor
apropiado de BodySID.
6. Las particiones con diferente BodySID se pueden multiplexar.

22. Resumen de las Reglas de Inserción
 Tablas de Índice
1. Cada Contenedor de Esencia tien una Tabla Índice opcional.
2. Cada Tabla Índice se identifica con un único “IndexSID”
3. Cada Tabla Índice se puede dividir en Segmentos de “Index
Table segments” que son distribuidos sobre las particiones.
4. Cada “Index Table segment” estará secuencias en el fichero
físico aunque no necesariamente en particiones adyacentes.
5. Cada partición identifica su “Index Table segment” con el
mismo valor de “IndexSID” de la Tabla Índice
6. Particiones con diferentes Index SID pueden ser Multiplexdas.

23. Estructura lógica en MXF
Metadata Header

24. Metadata
• Dentro del Header Metadata existen dos
tipos de datos:
– Estructural
– Descriptiva
El Header Metadata es una
secuencia de metadatos
KLV que describen el File
Body

25. Metadata Estrucrtural – EM-
• El Objeto “Preface” incluye infamación acerca de
la versión MXF y del tipo de esencia (Essence
Containers “EC”) dando un UMID para cada uno
de ellos.
• El EC se describe dentro de un File Package
Metadata Set (FP).
• El FP contiene tracks para cada esencia (vídeo,
audio TC,...)
• El FP apunta también a un File Descriptor que es
necesario para poder decodificar correctamente el
fichero (aspect ratio, croma, número de bits,...)

26. Metadata Estrucrutal – EM-
• El Objeto FP apunta a los ficheros físico
definiendo un “input” siendo el output el
visualizado y que está descrito en el Material
Package (MP)
• Dentro del MP se señala a uno más ficheros físicos
(Source Clips “SC”) y a sus segmentos.
• El MP contiene una “Track” que define el inicio y
final de una Edit Unit Rate
• El Track posee una “Secuencia” que define la
duración de la salida
• La Secuencia puede estar dividida en uno más
clips físicos.

27. Metadata Estrucrutal – EM-

28. EM. Modelo Completo
Root Metadata Sets for Structural Header MetadataDiagram of a Generic Package in the Structural Header Metadata

29. EM. Modelo Completo
Root Metadata Sets for Structural Header Metadata

30. Patterns y Paquetes
Controlando la complejidad

31. Op1b

32. Op1c y 2c

33. Interoperabilidad
• Se trata de ser usado por cuantos más
sistemas mejor si necesidad de cambio de
formato.
• La primera mejora es trata VBI, ANC como
una pista de datos.
– Se pueden tener varios productos de vídeo
siempre a partir del mismo TC.
– Tener datos GPS como datos de código de
Tiempo

34. MXF AS-02, AS-03
No se trata de estándares sino de
aplicaciones asociadas en este
caso a MXF en su versión del
2004.
Desarrollado por los mismos que
hicieron el AAF para
postproducción
Su funcionamiento está pensado en
workflow.
AS-02 empaqueta todos los
contenidos asociados a una
producción en todos sus formatos.
AS-03 sólo toma los que que necesita
el servidor o aplicación en
concreto
Su funcionamiento se basa en
desempaquetar y empaquetar los
servicios necesarios sin tocar las
esencias.

35. Bibliografía
• EBU TECHNICAL REVIEW – 2010 Q3
• EBU TECHNICAL REVIEW – 2010 Q3-2
• EBU TECHNICAL REVIEW – July 2002
• EBU – Recommendation R 122. Material Exchange Format Timecode
Implementation
• www.pro-mpeg.org
• Broadcast Engineering Janury 2011
• www.wamva.tv
• www.mog-solution.com
• www.freemxf.org

36. MXF en estándares

37. Estándares en MXF
• SMPTE377M Format • SMPTE 388M VBI
• SMPTE378M OP1a • SMPTE 389M DMC
• SMPTE379M Generic • SMPTE 390M OP-Atom
Container • SMPTE 391M OP1b
• SMPTE380M DMS1 • SMPTE 392M OP2a
• SMPTE381M MPEG • SMPTE 393M OP2b
• SMPTE382M Audio • SMPTE 394M OP3c
• SMPTE383M DV • SMPTE EG41
• SMPTE384M Uncompressed Engineering Guideline
• SMPTE385M CP compatible • SMPTE EG42
system DMS Engineering Guideline
• SMPTE386M D10 • SMPTE EG43
• SMPTE387M D11 Catalogue of MXF
Enumerated values