En la vista de metadatos, hay dos diferentes tipos de paquetes: un Paquete de Material (Material Package), que describe la línea de tiempo de un archivo MXF y lo que va a suceder cuando se pulse el botón ‘play’, y un Paquete de Archivos (File Package), que describe el vídeo y el audio almacenados físicamente en el archivo.
Es posible tener dos archivos MXF que tengan metadatos idénticos, pero estén físicamente dispuestos en dos formas diferentes, para optimizar algún elemento de un flujo de trabajo. En un archivo con una envoltura de frame de tipo OP1a por ejemplo, todo lo que hay en ese archivo está entrelazado cuadro por cuadro. El mismo activo, podría ser físicamente dispuesto como un conjunto de archivos componentes sincronizados por un archivo de versión MXF AS-02. Debido a que el MXF permite separar las vistas de metadatos y la vista física, permite un perfecto intercambio de media y metadatos de vital importancia que van con ella, y permite la creación de diferentes tipos de MXF, optimizados para flujos de trabajo específicos.
Los diferentes tipos de MXF
El MXF fue desarrollado con una enorme cantidad de aportes de la comunidad de usuarios, para asegurarse de que el formato realmente iba a satisfacer sus necesidades. La flexibilidad resultante también permitió a los proveedores, desarrollar su propia interpretación del estándar para sus codecs, como un diferenciador competitivo. Esta flexibilidad inherente ha llevado a la implementación de una serie de diferentes tipos de MXF, cada uno de ellos con metadatos MXF similares, pero aplicando diferentes vistas físicas, optimizadas para diferentes aplicaciones.
Comencemos con el genérico OP1a: OP1a es una implementación “tape-like” simple del formato MXF, que almacena los datos de audio y vídeo en un único archivo MXF entrelazado. Es flexible y no contiene restricciones reales sobre las normas de construcción de archivos. Esto hace que su aplicación sea realmente muy simple. Pero tiene la desventaja de sufrir problemas de interoperabilidad cuando diferentes proveedores interactúan sobre este.
Un pariente cercano del OP1a, es el formato XDCAM HD. Diseñado por Sony, el XDCAM HD es mucho más restringido que el OP1a. Tiene mucho mejor interoperabilidad, y tiende a ser utilizado principalmente en flujos de trabajo que requieren bajas tasas de bits, tales como HD a 50 Mbps. El lado negativo es que, está especificado para tener un máximo de 8 canales de audio AES mono, y aún con estas limitaciones, los problemas de interoperabilidad persisten. En la actualidad existe un grupo de trabajo, dentro de la Advanced Media Workflow Association (AMWA) examinando la interoperabilidad del XDCAM, y definiendo una variante aún más limitada llamada AS-10.
Así que, ahora vamos a echar un vistazo a una de las versiones en componentes más comunes de MXF, el OP-Atom.
Avid fue uno de los principales contribuyentes para el estándar MXF y, como tal, patrocinó la creación de una variante particular de MXF, el denominado Op-Atom. Es altamente restringido, sólo permite un componente, y toda la sincronización de los componentes se realiza en el archivo AAF. Sin embargo, los archivos OP-Atom generados por el Media Composer de Avid, tienen a menudo metadatos no-MXF en ellos. Esto se conoce como “metadatos oscuros” y puede llevar a problemas de interoperabilidad, en el intercambio de archivos entre diferentes fabricantes.
El sistema P2 de Panasonic también utiliza OP-Atom para grabar la esencia real de vídeo y de audio. El formato P2 es muy limitado, con buena interoperabilidad y uso extensible de metadatos. Sin embargo, hay ciertos límites en el tamaño del archivo P2, que pueden causar problemas operacionales. Por otra parte, el diseño P2 ha optado por un formato XML y no MXF, para sincronizar el audio y el vídeo. A pesar de que el archivo de sincronización XML hace referencia a la media almacenada MXF, la estructura del XML puede perder metadatos en la ida y vuelta, con un archivo MXF genérico.
Hay otra variedad de MXF con componentes, utilizada por Digital Cinema, que usa una vez más, una forma diferente para sincronizar archivos, llamada CPL (Composition Play List). Este archivo XML tiene una estructura diferente de la XML de P2, y la AAF de AVID. Si bien es un formato muy, muy limitado, que se adapta muy bien a todos los aspectos de la entrega de cine digital, está limitado a espacio de color RGB y JPEG 2000, que hace que sea demasiado restringido para un formato de intercambio de propósito general, y no apto para flujos de trabajo de televisión.
Como estamos empezando a ver, a pesar de los esfuerzos del estándar MXF para asegurar el funcionamiento sin fisuras entre los diversos proveedores, los distintos ‘tipos’ de MXF siguen dando lugar a problemas de incompatibilidad. Y, mientras la interoperabilidad está mejorando, a medida que los fabricantes están aprendiendo a implementar mejor los estándares, los usuarios siguen teniendo algunas frustraciones creadas por los sistemas incompatibles, que no pueden leer las versiones ajenas de los archivos MXF.
Este problema, ha dado lugar a una renovada colaboración entre las empresas de media, incluyendo a AmberFin y una docena de proveedores a través de la AMWA, para la elaboración de algunas Especificaciones de Aplicación (AS) como base para la interoperabilidad sencilla y fácil.
Las Especificaciones de Aplicación no son particulares para cualquier proveedor. Ellas definen un conjunto de restricciones sobre cómo se construye el archivo, para que coincida con los requisitos técnicos y operacionales en un punto particular del flujo de trabajo.
Si se necesita de restricciones aún más estrictas, por ejemplo, para las prácticas técnicas de un broadcaster, un género particular de programa, o un canal de distribución, estas se pueden definir como “cuñas”, un conjunto de restricciones de instalación-específica, que son definidas por la empresa y escritas en un documento gestionado y de versión controlada.
El AS-02 y AS-03 de MXF, por ejemplo, se han diseñado para optimizar flujos de trabajo basados en archivos dentro y entre organizaciones.
El AS-02 es una herramienta de masterización; está diseñada para satisfacer las necesidades de los creadores y distribuidores de contenidos, que se enfrentan a los retos del programa de control de versiones. Con el AS-02, el audio, vídeo y datos se almacenan en archivos de media independientes, para habilitar el eficiente control de versiones de programas, para su distribución. El AS-02 es un formato de archivo “componentizador”, no es un archivo único, sino un conjunto de elementos unidos bajo el concepto de un paquete, recogidos en una carpeta. Un paquete es completamente autónomo, y cuenta con todos los activos y metadatos necesarios para generar varias versiones de un programa, para su uso en un entorno de media multi-versión, multi-idioma y multi-entrega.
Hoy tenemos un soporte de “lectura” muy bueno para este formato, pero el de “escritura” está rezagado. La estructura del AS-02 puede hacer flujos de trabajo multi-versión muy rápido, y producir una cierta carga en la infraestructura de red de una instalación.
El AS-03 de MXF está destinado a la entrega de contenido terminado, directamente a un servidor de playout. El AS-03 obliga a la caja de herramientas de MXF a llevar, de manera eficiente, resultados finales en un formato compacto, robusto y reproducible directamente. Un archivo AS-03 es siempre un único archivo, para un único programa. El contenido de estos archivos no está destinado para procesamiento, sino para playout directo desde cualquier servidor. El archivo contiene un programa acabado o un segmento de programa, con sus metadatos asociados, y por lo general incluye vídeo, audio y subtítulos, más metadatos técnicos y específicos de AS-03, describiendo el archivo. Los archivos AS-03 contienen conjuntos de metadatos definidos, para la identificación y verificación del contenido frente a los metadatos de tráfico entregados.
El AS-03 funciona a la perfección para la entrega de contenido MPEG2 a servidores de playout, pero necesita algunas modificaciones, si desea utilizar el mismo formato para contribución entre broadcasters y empresas de post-producción. Para hacer frente a estas diferencias de aplicación, la AMWA está desarrollando el AS-11, un formato de archivo para la entrega de la programación finalizada, de productores de programa para estaciones de broadcast, o instalaciones de creación de programas. Sobre la base del AS-03, el AS-11 debe permitir códecs que sean MPEG (o no MPEG) con mayores tasas de bits, para fines de contribución. Una primera implementación del AS11 está siendo propuesta por la UK Digital Production Partnership del Reino Unido, basada en el códec AVCIntra.
Este fue un recorrido muy rápido por algunos de los formatos MXF más comunes. Al planear su flujo de trabajo, vale la pena considerar cuidadosamente cuándo puede utilizar cada uno de ellos: si se encuentra en un entorno en el que quiere hacer flujos de trabajo de control de versiones de audio, o en un ambiente donde usted necesita almacenar diferentes componentes para diferentes bits de flujo de trabajo, algo como el AS-02 tiene mucho sentido. Pero si lo que está tratando de hacer es mover esencias más metadatos en conjunto por ejemplo cuando usted mueve desde A hacia B, entonces un formato como el AS-03 o AS-11 puede ser más apropiado. Después de todo, estas Especificaciones de Aplicación han sido definidas específicamente, para ayudar a la comunidad de usuarios a obtener una mayor interoperabilidad, y tener un trabajo más fácil al elegir el formato MXF correcto en el momento y lugar adecuado.
Si está trabajando con MXF y está interesado en contribuir a su desarrollo continuo, puede ir al sitio web de SMPTE, http://smpte.org y unirse a la comunidad de estándares. El sitio web contiene una lista de todos los grupos a los que puede unirse. También está el libro de MXF, que le dará un buen recurso de lectura sobre lo que el estándar MXF tiene por finalidad. Sobre todo, recuerde que el MXF no es sólo un formato de archivo. Es simplemente una herramienta para construir grandes flujos de trabajo basados en archivos. El éxito del MXF dependerá de cómo usemos esa herramienta.
