DCP, un acercamiento práctico al estándar de proyección de cine (V)

Tras ver cómo es necesario crear contenedores de medios para facilitar el trabajo con los fotogramas y los canales de audio, en este punto veremos cómo relacionar y llamar en reproducción esos archivos. El “player” necesita saber para cada DCP qué archivos tiene que reproducir a la vez (audio y fotogramas) y en qué orden.  La manera de indicar al reproductor esa información es mediante unos archivos específicos XML. Con esto terminamos de ver la estructura de archivos del DCP y podremos pasar a examinar las herramientas de masterización que nos van a facilitar la labor de creación de nuestro paquete de proyección digital.

Etiquetando nuestra mejor cosecha: los descriptores para el servidor

La estructura más sencilla de un DCP (figura 1) contiene los dos archivos contenedores MXF que vimos en el apartado anterior, uno de audio (audio track) y otro de vídeo (video track). Además, aparecen cuatro archivos XML, donde dos de ellos son VOLINDEX y ASSETMAP -los descriptores del contenido- y los otros dos son los llamados PKL (Packaging List o listado del paquete) y CPL (Composition Playlist o lista de reproducción).

El formato Interop DCP contiene una relación similar de archivos pero cambiando la estructura y algunas referencias internas. Las diferencias son muy pequeñas pero condicionantes en algunos servidores de medios, por eso algunas productoras han creado discos DCP mixtos. Aunque existen múltiples opciones para una distribución mixta, sólo dos de entre las posibles –“múltiples directorios de alto nivel” y “mapa dual de elementos”- han sido validadas por el ISDCF (Inter-Society Digital Cinema Forum), con preferencia a la primera de ellas (figura 2).

Los archivos XML (eXtensible Markup Languaje) son archivos de texto plano -legible y modificable por cualquier editor de texto- y estructurado -poseen una sintaxis propia que facilita la identificación y acceso de los metadatos contenidos- que se usan para intercambiar información básica entre sistemas. El idioma usado es el inglés, debido a su expansión y a que es el idioma usado por defecto en el cine (¡no olvidemos que Hollywood y el DCI son americanos!).
Los archivos XML necesarios en un DCP son, como hemos comentado antes, el descriptor de la unidad de almacenamiento (VOLINDEX). El concepto de unidad o volumen hay que entenderlo en sentido amplio y puede ser un disco duro externo, una partición de éste o incluso, como hemos visto en los sistemas mixtos, un directorio. Todas las identificaciones se realizan mediante la asignación de un número único y especial (Universally Unique Identifier o UUID) a cada unidad, fichero y archivo. Esta asignación permite, independientemente del nombre que tenga, marcar el elemento de forma unívoca (podemos entenderlo como el DNI de cada ciudadano del país DCP). El otro archivo descriptor es el mapa de los contenidos (ASSETMAP) del DCP. Aparte de indicar qué archivos son los propios del DCP, apunta dónde se encuentran en la estructura de archivos (su camino o path) e, igual que ocurría con VOLINDEX, refleja el UUID de cada uno de ellos. Este archivo permite además que archivos muy grandes de un DCP se encuentren repartidos es unidades diferentes, lo que se conoce como DCP multivolumen, para lo cual indicará entre sus metadatos todos los VOLINDEX y sus UUID que contienen los trozos del archivo dado. En resumen, ASSETMAP y VOLINDEX serán los encargados de indicar al servidor de medios cómo se llaman y dónde se encuentran todos los archivos que conforman ese DCP. Además, proveen el UUID de cada elemento de forma que se comprueba que no falta ningún archivo y que éstos son los que deberían ser y no otros, independientemente del nombre dado. Es el primer paso en la ingesta del DCP.

Por otro lado,  el PKL parece que tiene una función parecida a ASSETMAP y, en cierta manera, la tiene: asegurar la integridad del DCP. Sin embargo, ahora veremos cómo se complementan entre ellos y las funciones asignadas tan diferentes que tienen. El PKL es el inventario de todos los archivos pertenecientes al DCP, con nombre, identificador único y un dato muy importante: su hash. Así como el UUID es un valor muy grande asignado aleatoriamente, el hash es un valor único pequeño, resultado de pasar el archivo por una función matemática (algoritmo) conocida. Estos valores sirven para detectar cualquier modificación, manipulación o error durante la transmisión (descarga de red, transmisión satélite, copia desde una unidad) de un archivo. El servidor es el encargado de calcular para cada archivo que copia del paquete DCP su valor hash y luego compararlo con aquel proporcionado por el PKL, de forma que se comprueba la integridad de los datos. Pero los metadatos del PKL alcanzan más allá, y entre ellos se encuentra el autor del DCP (quien posee los derechos de explotación), el sistema usado para la creación del paquete, etc.
El archivo CPL es la sesión de cine propiamente dicha, que puede ser para una película, un cortometraje, un anuncio, un trailer o una secuencia de los anteriores. Como si de una escaleta se tratara, indica a nivel interno cómo se relacionan los diferentes tracks (audio, vídeo y subtítulos) y el orden de reproducción de éstos durante la sesión. Esto se llama múltiplex temporal, es decir, una reproducción simultánea y sincronizada de varios archivos –en este caso de los MXF de audio y vídeo- (figura 3). Un DCP puede contener varios CPL y cada track puede ser referenciado por más de un CPL (figura 4). Esto aporta flexibilidad y permite reducir el volumen de datos a transportar para diferentes sesiones. De esta forma  pueden crearse versiones de diferentes idiomas, opción de sólo reproducir el trailer, incluso versiones extendidas y reducidas, todas en un solo DCP.

Los tres mosqueteros: ¡todos para uno y uno para todos!

Después de ver la teoría que se oculta tras los archivos del DCP, ya es hora de lanzarnos con conocimiento de causa a la creación del DCP propiamente dicho. Seguro que durante todo el recorrido hemos pensado ¿porqué a nadie se le habrá ocurrido juntar las herramientas vistas hasta ahora en un mismo entorno de creación de DCP?, ¿porqué no se ha realizado un programa visual que no requiera de la línea de comandos? Todas estas plegarias se han hecho realidad. Por fin es tan fácil crear un DCP como lo es un DVD o un Blu-Ray.
Es hora de analizar los paquetes de software libre que disponemos a día de hoy para nuestro trabajo y los condicionantes que deberemos asumir antes de decantarnos por una u otra solución. Son bastantes las herramientas disponibles para el trabajo de crear DCPs y todas se basan en las mismas herramientas libres y licencias GPL que hemos ido repasando poco a poco en los puntos anteriores. Del conocimiento de los conceptos que se ocultaban en estas herramientas podremos extraer todo su potencial, flexibilizarlas y adaptarlas a nuestro flujo de trabajo que, seguro, es diferente y único para cada persona y producto audiovisual. De ahí que hayamos querido dotar de las primeras entregas de una carga un poco más teórica que práctica.
Estos paquetes de software agrupan las múltiples herramientas de línea de comandos bajo interfaces gráficas de usuario, más comúnmente conocidas como Graphical User Interface o GUI. Éstas nos van a facilitar enormemente el trabajo: nos van a permitir optimizar nuestro trabajo, nos van a ahorrar tiempo y nos van a hacer transparentes muchos pasos complicados como la asignación de los UUID, usar correctamente la convención de nombres para el título del producto -ContentTitleText de la figura 3- establecida por el DCI, multiplexar u ordenar correctamente los canales de audio, juntar ordenadamente la secuencia de fotogramas JPEG2000, etc. Todo el trabajo “sucio” -una mezcla entre engorroso y delicado- está, en mayor o menor medida, programado y automatizado, mientras siempre sepamos lo que estamos haciendo. Las herramientas que vamos a ver han sido programadas con pasión y conocimiento, pero con mayor o menor fortuna.
Nuestra función será elegir el software para este trabajo e indicarle correctamente los parámetros necesarios para la creación de nuestro DCP que, normalmente, serán: el directorio con nuestros fotogramas, los archivos de los correspondientes canales de audio y el directorio donde almacenar los archivos MXF, XML y el DCP resultantes. Incluso pueden usarse de forma modular o -ya veremos cuáles- usar solamente partes de ellas como la compresión, la creación de los contenedores o la formación de los archivos XML finales, en función de la personalización de nuestro flujo de trabajo. Vamos a ver con detalle cuáles son, qué nos ofrecen y cómo se adaptan a nuestras necesidades (ver también tabla 1):
–    OpenCinemaTools (OCT) DCP Maker (v.1.1.2) es el más veterano y, a pesar de su nombre terriblemente comercial, es un software libre que nos ayuda en la creación de los archivos necesarios, totalmente compatibles con SMPTE DCP. Se puede usar en línea de comandos con todos los sistemas operativos, pero posee como detalle una GUI bajo Windows que facilita el trabajo con los ficheros. Sin embargo, a pesar del beneficio aparente de su GUI, se trata de una herramienta que lamenta el paso del tiempo y la falta de atención de sus creadores; tiene fallos de operación y actualmente se encuentra sin soporte más allá de los foros de Internet. Sin embargo, funciona en Windows y en MAC, permite velocidades de 24 y 25 fps y nos permite realizar pasos tan importantes como la compresión JPEG2000. Para su descarga http://www.opencinematools.org
–    OpenDCP (ODCP) (v.0.19) es un software libre parecido a OpenCinemaTools pero con más posibilidades, opciones, facilidad de uso y mantenimiento (¡fue actualizado el 20 de abril de este año!). Le diferencia respecto al resto de herramientas que se ha desarrollado GUI para Windows y, atención, ¡otra idéntica para MAC OS X! . Es compatible con todos los estándares y nos ayuda en la creación del DCP de forma modular. Como contrapartida, de momento sólo acepta el formato TIFF para nuestros fotogramas. Está en desarrollo que acepte próximamente .DPX y .PNG. Es el actual top de la creación de DCP pues está diseñado para ser flexible y robusto. Para su descarga http://code.google.com/-p/opendcp/
–    Digital Cinema package Creator (DCPC) (v.1.4.3.5) es un software libre compatible con ambos estándares MXF actuales. Es de desarrollo alemán -con traducción al inglés- y posee una imagen muy similar a opencinematools pues posee una GUI bajo Windows para su manejo que se corresponde fielmente con la anterior. Permite incluso la conversión al espacio de color XYZ (hay que marcar la casilla correspondiente al inicio del programa). Atención porque la compresión de los fotogramas a JPEG2000 no es opcional y se ejecuta siempre. Como no todo podía ser perfecto, incluso a pesar de su capacidad de trabajar con múltiples procesadores, la ejecución del programa falla algunas veces. Acaba de ser actualizada este 15 de abril. Para su descarga http://cinema.terminal-entry.de/
–    Digital Cinema Package GUI (2DCP_GUI) es un software con interfaz Windows y autoría alemana que, quizás, sea su mayor handicap… ¡no se entiende nada! Bromas aparte –existen multitud de traductores que nos pueden ayudar a saber a qué se refiere cada campo- el programa no comparte apariencia con ningunas de las GUI  vistas anteriormente. Permite la compresión JPEG2000, aplicar el espacio de color XYZ a las imágenes y usar la potencia de múltiples procesadores de nuestros equipos. Para su descarga www.mik-digital.de
–    AS-DCP es una librería de implementación software libre para generar MXF compatible con SMPTE e Interop. Todos los paquetes de software anteriores se basan en esta librería, sólo que han sabido hacer su uso transparente al usuario y ya no debemos caer de nuevo en el duro trabajo de la línea de comandos. Sin embargo, no nos ayuda en la creación de las listas de reproducción (CPL) ni del PKL. Para su descarga: http://www.as-dcp-lib.org
Lo ideal es, siempre, llegar a este punto con los deberes terminados en función del software elegido y de nuestro flujo de trabajo. Tenemos dos posibles opciones: controlado o asistido. Si lo que queremos es controlar nuestro flujo de trabajo de principio a fin, tener flexibilidad y mantener la calidad máxima en cada paso, entonces usaremos OCT DCP Maker, openDCP o la librería AS-DCP. Los dos primeros son herramientas modulares y podemos usar, por ejemplo, sólo la ayuda en la creación de los contenedores MXF y del empaquetado DCP final que son, quizás, los pasos que más dificultad conllevan por la convención de nombres, títulos y UUID.
Sin embargo, si lo que deseamos es asistencia en cada paso (¡incluso de la conversión de color XYZ y de la compresión JPEG2000!), entonces podemos ayudarnos de las herramientas openDCP, DCPC o 2DCP_GUI. Por ejemplo, a la herramienta DCPC bastará con indicarle el directorio donde guardamos los fotogramas en cualquiera de los formatos que acepta esta herramienta (BMP, TIFF o DPX) para que nos automatice el resto de pasos hasta la creación final del DCP en el directorio que le hayamos indicado. Sin embargo, hay que tener en cuenta que algunos de los pasos se realizan siempre y, en el caso concreto de 2DCP_GUI la conversión de color de los fotogramas se realiza siempre. Otras herramientas poseen la capacidad de elegir como opciones la corrección de color, la compresión JPEG2000, etc. (mejor ver la tabla 1). Queda desterrado a partir de este momento, para aquellos usuarios menos expertos o que no quieran complicarse más, el modo terminal (también llamado línea de comandos) que vimos números atrás. Estoy seguro de que habrá muchos lectores a los que esta noticia les va a animar a hacer su primer DCP.

Si en los puntos anteriores veíamos cómo los usuarios de Windows se veían claramente beneficiados por las herramientas software desarrolladas y una instalación y manejo más sencillos, tras la aparición de openDCP -con GUIs para Windows y para MAC OS X- el tema parece que se invierte. Si en algo destaca Apple es por la estabilidad, rendimiento y eficiencia de sus sistemas, que no es de extrañar pues está basado en una distribución de Linux (concretamente en la FreeBSD). Dejándonos de anécdotas y entrando al tema que nos interesa, vamos a comentar los campos de las cuatro GUI disponibles, todas válidas bajo Windows y sólo una –openDCP- probada con éxito en MAC OS X 10.5 (Leopard) y 10.6 (Snow Leopard). Elegiremos siempre el formato 2D (no estereoscópico si nuestra producción no es 3D) y resolución 2K allí donde nos pida datos acerca del formato de trabajo deseado.
En OCT identificamos con facilidad la función de cada campo que, si los comparamos con los de DCPC, vemos que se parecen como dos gotas de agua. La única diferencia apreciable es que DCPC usa como partida nuestros fotogramas sin compresión -sólo la conversión al espacio de color XYZ es opcional- y nos obliga siempre a usar la compresión propia JPEG2000 de este software si queremos hacer uso de él, mientras que OCT tiene la opción de usar los fotogramas sin comprimir (campo “JPEG 2000 Encoding”) o los fotogramas finales (campo “MXF Wrapping”) ya preparados para encapsular en MXF conforme al estándar SMPTE DCP. Al DCPC, a nivel de metadatos,  sólo le falta poder introducir la descripción del PKL y del ASSETMAP, que rellena de forma automática con el dato del creador dado para el CPL.
AS-DCP representa el escalafón más bajo de las herramientas, sin embargo es la base de la creación de los MXF y XML. Se trata de la librería de bajo nivel en la que se basan el resto de productos y que solamente opera a nivel de línea de comandos. Es válida tanto para MAC como para Linux como Windows, pero es complicada de manejar debido al gran número de parámetros que hay que tener en cuenta.
Si el medio por el que nos movemos es MAC, nuestras opciones se reducen a tres: openDCP, OCT y AS-DCP. Evidentemente aquí apostaremos al caballo ganador: openDCP. Se trata del último software para creación de paquetes DCP y, con toda seguridad, el más maduro, completo, estable y modular. Nos permite en tres sencillos pasos (todos opcionales) obtener un DCP válido y estandarizado SMPTE bajo este sistema operativo que siempre se había mantenido en el limbo en cuanto a soporte de las herramientas de código abierto DCP. Ahora, por fin, podemos desde nuestro MAC crear DCPs como los usuarios de Windows pero con mayor estabilidad en los procesos. El único detalle es que el punto de partida de esta herramienta son fotogramas TIFF (con cualquier profundidad de color). En breve, ha anunciado su creador, se ampliará la aceptación de otros formatos de archivos gráficos como DPX.

Nuestro mejor aliado: openDCP

Debido a sus características, vamos a centrarnos en explicar la herramienta openDCP, válida para Windows y MAC. Antes de ejecutar este software debemos exportar a fotogramas TIFF nuestro DSM para crear el DCDM definitivo. Si nuestro DSM tienen más de 8 bits por muestra, es preferible exportar desde Adobe After Effects, Avid Media Composer o Apple Shake con los ajustes apropiados de sus parámetros para obtener una salida de secuencia TIFFs de 16 bits que respete la reproducción tonal de nuestra fuente. Otra opción sería exportar nuestros fotogramas en DPX, que muchos programas de edición ya contemplan como opción de exportación, y con ayuda de ImageMagick convertir a TIFF 16 bits. Si no disponemos de estas herramientas, exportaremos a secuencia TIFF sencilla de 8 bits por muestra desde nuestro programa de edición o desde herramientas propias de compresión como Adobe Media Encoder, Apple Compressor o MPEGStreamclip.

Podemos aprovechar la exportación de los fotogramas para escalar y recortar nuestro DSM, en caso necesario, a los tamaños posibles de fotograma: flat (1998×1080 para 1,85:1) y scope (2048×858 para 2,39:1). No ganaremos en calidad de imagen pero sí en aprovechamiento del área de proyección puesto que estos tamaños se adaptan a la altura y a la anchura respectivamente del formato 2K. Haremos este procesado ahora puesto que con esta herramienta posteriormente no habrá opciones de recorte de imagen.
Ya podemos abrir el programa donde disponemos de tres pestañas que siguen el flujo de trabajo ordenado: JPEG2000, MXF Creator y DCP Package. El primero de los pasos comprime nuestros fotogramas TIFF al formato específico de JPEG2000 establecido por el DCI. En este paso podemos realizar también la conversión de color XYZ. A diferencia de cuando vimos este proceso con ImageMagick, ahora no sabemos el valor gamma de linealización ni la matriz primaria normalizada (NPM) usados en la conversión ni podemos adaptar ningún valor a nuestro entorno de trabajo.
Puede que nos interese recortar, reescalar y procesar la gamma y el color XYZ de nuestros archivos con ImageMagick y comprimirlos con OpenJPEG (“image_to_j2k”) de forma totalmente manual como vimos en entregas anteriores. O quizás sólo ejecutar la conversión completa con ImageMagick pero realizar la compresión JPEG2000 con ayuda de openDCP. Vemos que podemos hacer estos pasos de forma modular, incluso hacer sólo aquellos que nos interesen. ¡Con este programa todo es posible!
La primera de las casillas nos pide rellenar los parámetros del codificador JPEG2000. Debemos indicarle varios parámetros para que la compresión se realice con éxito:
–    Encoder: el codificador a usar. Por defecto está “openJPEG”, tal y como habíamos visto en la tercera entrega pero ahora de forma fácil y transparente para nosotros.
–    Profile: el formato DCI. En nuestro caso “cinema 2K”, salvo que nuestro punto de partida sea un material de Red One grabado en 4K (aunque la cámara no rinde más allá de 3K reales).
–    Frame rate: la tasa de fotogramas. A pesar de existir la opción de 25 fps, elegimos 24 para proyección 2D. De esta forma nos aseguramos compatibilidad con todos los servidores del mercado. Si nuestro proyecto fuera 3D o estereoscópico, elegiríamos 48 fps (24 para cada ojo).
–    Bandwidth: la tasa de datos máxima. Tener en cuenta que la calidad obtenida con valores mayores de 160 Mb/s es indistinguible visualmente de 250 Mb/s. Reducir la tasa de datos nos ayuda a ahorrar tiempo de procesamiento y espacio en disco duro.
–    Threads: el número de hilos de CPU. Se refiere al uso de la capacidad de cálculo de nuestra máquina y por defecto elige automáticamente el total de los núcleos/hilos disponibles de los procesadores. Cuantos más hilos asignemos, más fotogramas podrán procesarse en paralelo.
–    XYZ Color Conversion: la conversión de color. A nuestra elección marcar o no, en función del origen de nuestros fotogramas.
Tras esto, debemos señalar el directorio (Input Directory) donde habremos guardado nuestros fotogramas TIFF y luego decirle el directorio (Output Directory) donde queremos que nos almacene los fotogramas codificados en el nuevo formato .j2c. Ya sólo nos quedaría pulsar el botón de convertir, que inicia la sesión. El Preview no nos ha funcionado en ninguna de las versiones GUI ni en ningún sistema operativo; habrá que esperar a la versión 0.2.
En pruebas de rendimiento de compresión a máxima tasa de datos (250 Mb/s) -con conversión de color incluida- para un material de 20 minutos de duración, el tiempo de procesado alcanzó las dos horas con un equipo con 16 núcleos Intel Xeon a 2,66 GHz. ¡Esto nos da un factor de 6:1 para un ordenador valorado en 6000 euros! A pesar de la gran tasa de datos durante la lectura escritura de los archivos, el uso de discos en configuración RAID 0 sólo puede mejorar estos tiempos levemente debido a que se trata básicamente de un  proceso de alta carga de CPU. Donde más vamos a notar la reducción de los tiempos en este primer paso de la creación del DCP es invirtiendo en un mayor número de procesadores con varios núcleos cada uno y, éstos, a la mayor velocidad de reloj posible.
La segunda de las pestañas trabaja en la creación de los contenedores MXF de imagen y sonido. La herramienta está diseñada para poder trabajar de forma compatible con ambos estándares MXF: Interop y SMPTE. Nosotros elegiremos siempre SMPTE salvo que nos indiquen desde el exhibidor que su servidor es sólo compatible Interop. Los parámetros que debemos indicarle son:
–    Source: el formato de nuestras fuentes comprimidas. El sistema necesita saber si le vamos a proveer de fotogramas JPEG2000 (nuestra elección) o de un archivo único MPEG2 (método en desuso).
–    Package: formato de nuestros archivos contenedores: SMPTE o Interop.
–    Frame Rate: la tasa de fotogramas. 24 en nuestro caso para proyección 2D.
–    Stereo/5.1: canales de audio de la configuración del diseño sonoro: estereofónico 2.0 ó envolvente 5.1. Este punto es especialmente importante para aquellos que no quieran simular una mezcla envolvente en postproducción y con tan solo exportar los canales izquierdo (Left) y derecho (Right) desde su sistema de edición no lineal estarán en disposición de crear su DCP. Sin embargo, recuerdo que en la segunda parte del artículo, allá por marzo, explicábamos las razones de la necesidad de crear una mezcla envolvente y los métodos para ello a partir de nuestro estéreo.
–    Picture Input: directorio donde están los fotogramas JPEG2000.
–    Sound Input: archivos de sonido de cada canal para la configuración de audio elegida.
–    Output Files: elegiremos el directorio y los nombres de los archivos video track y audio track que se van a crear.
Cuando pulsemos el botón Create MXF, iniciará la creación del MXF de imagen o video track copiando en un solo archivo y de forma ordenada e indexada los fotogramas conforme a la estructura vista en la entrega TM Broadcast anterior. Atención, porque tras completar la parte de imagen aparecerá un aviso que indica la finalización de la creación del MXF de imagen y hasta que no aceptemos el mensaje no se iniciará la creación del MXF de audio. Este proceso puede realizarse incluso con un portátil pues ya no existen altas exigencias de CPU. La creación de cada contenedor no cuesta más del tiempo total de la copia de sus archivos Input. Podemos comprobar cómo cada archivo MXF ocupa en disco casi lo mismo que el directorio que contenía nuestras fuentes. En este proceso sí es recomendable disponer de discos en configuración RAID 0 o, en su defecto, trabajar con un disco duro en lectura y con otro en escritura, bien internos en diferentes bahías, bien externos con conexiones de alta velocidad como SATA, USB 3.0 ó Firewire 800. En nuestras pruebas, el tiempo arrojado trabajando con discos duros externos Firewire 800 ha sido la mitad del invertido en la compresión JPEG2000.

Txt: Gorka Larralde