MXF. Aclaremos dudas

En el pasado curso de creación de DCPs que impartimos en 709 pude ver que había ciertas dudas con respecto a los tipos de MXF que existen. La duda apereció cuando expliqué que la imagen y el sonido de las copias de cine digital (DCP) van encapsuladas en sendos MXF y estos son diferentes, por ejemplo, de los que se graban en XDCAM y P2 o de los que utilizan los sistemas de edición como AVID. Pues como lo mejor es siempre aclarar las dudas aquí os dejo un artículo que espero os sea útil.

MXF (Material Exchange Format) es un formato de archivo dirigido al intercambio de material audiovisual con metadatos asociados entre distintas aplicaciones. Sus características técnicas están definidas en el estándar SMPTE 377M y fue desarrollado por el Pro-MPEG Forum, la organización EBU y la asociación AAF, junto con las principales empresas y fabricantes de la industria broadcast. El objetivo final es un formato de archivo abierto que facilite el intercambio de vídeo, audio, datos y metadatos asociados dentro de un flujo de trabajo basado en archivos.

Un fichero MXF funciona como un contenedor que puede portar video, audio, gráficos, etc. y sus metadatos asociados, además de la información necesaria que conforma la estructura del archivo. Un factor importante es que MXF es independiente del formato de compresión utilizado, ya que puede transportar diferentes tipos de formato como MPEG, DV o una secuencia de TIFFs. La gran ventaja de MXF es que permite guardar e intercambiar los metadatos asociados, que describen el contenido y la forma en que el archivo debe ser leído.

Los metadatos pueden contener información sobre:

  • La estructura de archivos
  • El contenido en si (MPEG, DV, ProRes, DnxHD, JPG, PCM, etc.)
  • Código de tiempo
  • Palabras clave o títulos
  • Subtítulos
  • Notas de edición
  • Fecha y número de versión de un clip -Etc.

MXF se basa en el modelo de datos AAF (Avanced Authoring Format) y son complementarios entre ellos. La diferencia entre este formato y MXF es que el formato AAF está optimizado para procesos de posproducción, debido a que permite almacenar una mayor riqueza de metadatos y a que posibilita utilizar referencias a materiales externos. Los archivos MXF pueden incrustarse dentro de los archivos AAF, esto significa que un proyecto AAF puede incluir el contenido audiovisual y los metadatos asociados, pero también puede llamar a otros contenidos MXF alojados de forma externa.

Lograr la interoperabilidad es el objetivo primordial de MXF y se establecen tres áreas:

-Multiplataforma. Se trabajará a través de diferentes protocolos de red y de sistemas operativos, incluyendo Windows, Mac OS, Unix y Linux.
-Compresión independiente. No convertir entre formatos de compresión, lo hace más fácil manejar más de un formato nativo. Puede manejar el vídeo sin comprimir.
-Transferencia en streaming. MXF interactua a la perfección con los medios de streaming de modo bidireccional. SDTI es un ejemplo de transmisión basada en ficheros que funciona a la perfección con este formato. También la transmisión sobre redes IP es óptima.

Un fichero MXF tiene una estructura que alberga una cabecera de archivo donde se detallan el contenido del archivo y su sincronización, los metadatos asociados a la multimedia, el cuerpo que contiene la esencia de los datos multimedia originales y la cola que cierra el archivo.

Los datos contenidos en archivos MXF son almacenados usando una subdivisión en un trío de valores KLV (Key-Length-Value). Esto es una clave de identificación única (key) de 16 bytes para cada trío, el valor de la longitud (length) de los datos almacenados en ese trío y los datos en si (value). Este modo de organizar los datos permite localizar cualquier elemento específico dentro del archivo MXF, con tan solo leer las claves. Esta estructura también permite que el formato de fichero pueda crecer y añadir nuevas características con nuevas técnicas de compresión y esquemas de metadatos que se vayan definiendo.

Podemos rizar un poco más el rizo y es que se permiten particiones dentro de un trío KLV. Esto es que los datos de un trío pueden estar fragmentados en una sucesión de tríos KLV y le da mas robustez a la estructura del fichero. Esto tiene una ventaja, por ejemplo, en las transmisiones de ficheros MXF sobre redes, donde si perdemos la conexión y se corta la transferencia del MXF, al recuperarla no será necesario enviar el fichero entero de nuevo puesto que podremos enganchar en el trío donde se rompió la transferencia.

Hasta aquí supongo que todos lo tenéis bastante claro y os preguntareis el porqué un MXF que genera una cámara XDCAM no es compatible con el que genera una P2 si el formato MXF se creó para garantizar la compatibilidad. Pues bien, la gran flexibilidad del MXF permite distintas interpretaciones y aplicaciones de la norma por los distintos fabricantes, y así es como los MXF que generan los productos de cada uno no son compatibles entre sí. Esto ha llevado a implementar una serie de diferentes versiones físicas para mejorar la interoperabilidad en función de sus aplicaciones. De este modo se establecen los llamados Patrones Operacionales y cada uno tendrá sus especificaciones bajo un estándar propio que definirá el tipo de imagen/sonido que contiene la esencia y la estructura de los metadatos. De estos patrones, OP-1a y OP-Atom son los que nos encontramos más a menudo.

El patón operacional genérico es OP-1a y se creó como sustituto de la cinta de video, donde un solo archivo MXF contiene video, varios canales de audio y códigos de tiempo. Es muy simple y flexible pero tiene muchas limitaciones en cuanto a se tiene que trabajar sobre el. Un ejemplo en este caso sería el formato XDCAM o las cámaras de JVC que graban en tarjetas, donde cada uno de sus clips tienen un único archivo con el video y el audio.

OP-Atom es un formato de archivo muy simple que sólo puede tener en su esencia un único elemento, ya sea una pista de vídeo o de audio. Por lo general, la metadata vinculada a la media que contienen los MXF OP-Atom está en ficheros AAF o XML. Un ejemplo típico es el formato P2, donde las pistas de vídeo y audio se envuelven en ficheros MXF-Atom separados y la metadata que los asocia va en un fichero XML separado.

Los ficheros de media que genera AVID también son OP-Atom y su metadata asociada está en AAF. Este es el más utilizado en los entornos de edición, donde se requiere el acceso de forma individual a los componentes audiovisuales. En el caso de AVID, estos ficheros tienen la particularidad de incorporar unos metadatos no estándar de MXF que utilizan las aplicaciones de este fabricante para indexarlos y que pueden crear problemas de incompatibilidad si se intercambian con otros sistemas diferentes a AVID.

En el caso del cine digital, los MXF que llevan la imagen y audio también son OP-Atom. En este caso están restringidos a la compresión y espacio de color específicos para esta función (JPEG 2000 y XYZ) en el caso del video y a 16 pistas PCM en el caso del audio, por lo que su compatibilidad fuera de este entorno es muy limitada. Su sincronización y metadata está la información que llevan unos ficheros XML.

Después podemos establecer un grupo de patrones de operación (OP) con varios niveles de complejidad, donde el patrón OP-1a es el nivel más bajo. Una única pista continua con vídeo, audio y metadatos empaquetados en un archivo es lo que define el patrón OP-1a. El nivel más complejo dentro de estos patrones es el OP-3c, con la combinación de varios clips (archivos empaquetados) con varias listas de reproducción (playlist) combinadas. Aquí os dejo una tabla con ellos.

La Asociación AMWA (Advanced Media Workflow Association) se creó para liderar el desarrollo y fomento de la utilización de estándares y tecnologías que permiten unos flujos de trabajo más eficaces para el uso de la media en red. Sus proyectos actuales son el avance en el uso de los formatos AAF, BXF, MXF y XML en los lujos de trabajo basados en archivos de datos. Esta asociación trabaja en estrecha colaboración con la SMPTE y otros organismos de normalización.

Entre sus proyectos hay uno que hace referencia a los archivos MXF y define un conjunto de reglas que limitan la especificación MXF de cara a la adaptación de este formato a distintas aplicaciones y flujos de trabajo. Estas especificaciones se pueden resumir en la siguiente lista:

AS-02 – MXF con versiones de masterización. Este fue desarrollado para soportar el almacenamiento y gestión de los componentes de un programa en MXF, para permitir versiones, multi-idiomas y entregas a los diferentes medios de difusión. Es un paquete de archivos que cuenta con todos los elementos necesarios de video, audio y metadata para generar varias versiones de un producto. ¿Quién lo debe usar? Entornos de postproducción, los organismos de radiodifusión y los distribuidores de contenidos.

AS-03 – Entrega de programas. Esta especificación MXF está optimizada para la distribución del programa y su emisión directa desde un servidor de vídeo. Es un único archivo que incorpora audio, video y metadatos de un único programa. ¿Quién lo debe usar? Las redes de organismos de radiodifusión.

AS-10 – MXF para la Producción. La especificación de la aplicación AS-10 está orientada a establecer un formato de archivos MXF común para todo el flujo de trabajo de una producción, incluida la grabación en cámara, la ingesta en un servidor, la edición, la reproducción, la distribución digital y archivo.

Un ejemplo es el uso de MPEG Long-GOP. El proyecto incluye el desarrollo de una aplicación para validar los archivos como una ayuda para los procesos de control de calidad. ¿Quién lo debe usar? Producción y postproducción, los organismos de radiodifusión y distribuidores de contenido.

AS-11 – MXF para redistribución. Este es un formato de archivos MXF para la entrega de productos terminados desde las estaciones de difusión de los creadores de los programas. AS-11 incluye la funcionalidad del AS-03 y se extiende para incluir AVC-Intra 100, e incluye soporte para la norma de vídeo D-10 de definición estándar con audio AES3. AS-11 define un conjunto básico de metadatos mínimo, y un esquema de metadatos con la segmentación del programa. ¿Quién lo debe usar? Los organismos de radiodifusión, y los distribuidores de contenidos.

AS-12 – Entrega Comercial. AS-12 es un subconjunto de archivos en formato MXF para la entrega de anuncios acabados a las estaciones de televisión o redes de difusión. La especificación proporciona una claqueta y otros metadatos para asociarlos con la esencia del sonido y del vídeo. AS-12 establece que la identificación explícita de los contenidos se realice asistida por un ordenador y que este controlará la lista de reproducción. ¿Quién lo debe usar? Producción y postproducción, la distribución comercial, organismos de radiodifusión y redes de cable.

Las principales características de estos MXF están en la siguiente tabla, AS-02 no aparece por estar todavía sin cerrar definitivamente su proceso de desarrollo.

Y hablado del AS-02, AVID en su nueva versión 6.5 de las soluciones MediaComposer y Symphony da soporte a este formato. Un nuevo componente de AMA (Avid Media Access) llamado Avid Media Authoring nos permite a los usuarios entregar y archivar múltiples formatos de salida, entre ellos se encuentra el AS-02. Se incorpora un nuevo códec JPEG 2000 nativo y así se podrán empaquetar productos para multi-difusión, multi-versión, multi-idioma sin degradación del contenido. AS-02 en Avid soporta J2K, Uncompressed 10b RGB, DNxHD, AVCI, IMX y Uncompressed 8b para SD.

Cuando creemos un paquete AS-02 nos encontraremos con la siguiente estructura de archivos:

  • Asset.mxf es el archivo de la secuencia (versión).
  • Manifest.xml es un archivo que incluye información sobre el creador, fecha de creación, información sobre la versión y listado de todos los archivos y carpetas que contiene el paquete AS-02.
  • Shim.xml es una plantilla o archivo de configuración que limita las reglas para un uso específico.
  • La carpeta Media contiene todos los archivos de la media que incluye el paquete.
  • La carpeta Extra contiene una copia de la secuencia sin compactar en un archivo con una composición AAF. Esta carpeta también puede contener otros archivos adicionales que se desean incluir en el paquete, tales como guiones, gráficos, etc.

Aquí podéis descargar un documento sobre AS-02 y AVID

Recordaros también que estos contenidos son explicados en nuestro curso DCP. Creación de cine digital con software gratuito.

Aquí os dejo también la lista de los estándares que hacen referencia al formato MXF (fuente: wikipedia)

-DOCUMENTOS BASE:

SMPTE 377M: The MXF File Format Specification (documento principal general)
SMPTE EG41: MXF Engineering Guide (guía explicando cómo usar MXF)
SMPTE EG42: MXF Descriptive Metadata (guía explicando cómo usar los metadatos descriptivos en MXF)

-PATRONES OPERACIONALES:

SMPTE 390M: OP-Atom (un layout simple para ficheros MXF) SMPTE 378M: OP-1a

SMPTE 391M: OP-1b
SMPTE 392M: OP-2a
SMPTE 393M: OP-2b
SMPTE 407M: OP-3a, OP-3b
SMPTE 408M: OP-1c, OP-2c, OP-3c

-CONTENEDORES GENÉRICOS:

SMPTE 379M: Generic Container (cómo almacenar la esencia en los ficheros MXF)
SMPTE 381M: GC-MPEG (cómo almacenar los datos de esencia MPEG en MXF usando el Contenedor Genérico)
SMPTE 383M: GC-DV (cómo almacenar los datos de esencia DV en MXF usando el Contenedor Genérico)
SMPTE 385M: GC-CP (cómo almacenar los datos de esencia SDTI-CP en MXF usando el Contenedor Genérico)
SMPTE 386M: GC-D10 (cómo almacenar los datos de esencia SMPTE D10 en MXF usando el Contenedor Genérico)
SMPTE 387M: GC-D11 (cómo almacenar los datos de esencia SMPTE D11 en MXF usando el Contenedor Genérico)
SMPTE 382M: GC-AESBWF (cómo almacenar los datos de esencia audio AES/EBU i Broadcast en MXF usando el Contenedor Genérico)
SMPTE 384M: GC-UP (cómo almacenar los datos de esencia de imagen sin comprimir en MXF usando el Contenedor Genérico)
SMPTE 388M: GC-AA (cómo almacenar los datos de esencia de audio codificado con A-law en MXF usando el Contenedor Genérico)
SMPTE 389M: Generic Container Reverse Play System Element
SMPTE 394M: System Item Scheme-1 for Generic Container
SMPTE 405M: Elements and Individual Data Items for the GC SI Scheme 1

-METADATOS, DICCIONARIOS Y REGISTROS:

SMPTE 380M: DMS1 (conjunto de metadatos descriptivos para usar con ficheros MXF)

SMPTE 436M: MXF Mappings for VBI Lines and Ancillary Data Packets SMPTE RP210: SMPTE Metadata Dictionary
SMPTE RP224: Registry of SMPTE Universal Labels

 

8 comentarios de “MXF. Aclaremos dudas

  1. render dice:

    Podrías revisar un poco lo que escribes, hay párrafos que no tienen sentido. Frases mal construidas que, al estar hablando de temas complejos, confunden y desorientan al lector. Por favor, un poco de respeto al lenguaje escrito.

  2. pantera dice:

    hola media room muchas gracias por tu aporte, yo tengo una duda, que tamaño es el maximo para exportar un MXF, ya que a mi me los estan pidiendo en 2k y solo los he podido exportar en HD 1920 x 1080 se puede haser en 2k?

  3. ivan acuña dice:

    yo tengo un problema, hago video pero hace poco un cliente me pidió que su video en formato AVI, sea comprimido o encapsulado (supongo que ese es el termino) en XMF ya que el video debe ser subido a un servidor de una empresa de cine, que usa este tipo de ficheros para pasar publicidades en las pantallas de sus salas, mi pregunta es si existe algún software que pase de AVI o cualquier formato de video a compresión o encapsulado XMF, de ser así me gustaría que me orientaras al respecto, de antemano muchísimas gracias.

    • Fernando Alfonsín dice:

      Hola Iván,
      Si el destino es un servidor de cine digital, lo que te están pidiendo es un DCP. El DCP está formado por una extructura de archivos en los cuales el video y el audio van encasulados en sendos MXF y toda la metadata que los vincula en XML. La compresión del video en este caso será JPEG 2000. En 709 tenemos un curso específico sobre los DCPs, en el cual explicamos todas sus características y como hacerlos correctamente. Utilizamos software libre (OpenDCP y DCPBuilder).
      También puedes ponerte en contacto con http://www.dcplowcost.com, que prestan este servicio y están especializados en la creación de DCPs.
      Un saludo.

Deja una respuesta