tema 10 compresión de vídeo - ocw uned

Programa Oficial de Postgrado:

Master en Comunicaciones, Redes y Gestión de Contenidos

TECNOLOGÍA DE LOS CONTENIDOS MULTIMEDIA

Optativa de 2º cuatrimestre

TEMA 10

Compresión de Vídeo

TEMA 10

Compresión de Vídeo

10.1 INTRODUCCIÓN A LA COMPRESIÓN DE VÍDEO.

La compresión de sonido y de vídeo es hoy en día una necesidad conocida y las herramientas quese han desarrollado a lo largo de los últimos años han ido apareciendo en el mercado de consumocon intensidad relevante. La ventaja fundamental de la compresión va más allá del mero ahorroen los dispositivos de almacenamiento. Su mayor interés práctico se centra en las comunicacio-nes, especialmente mediante Internet, ya que influye decisivamente en la posibilidad de transferirelementos de audio y/o video mediante este medio.

La tecnología de la compresión de vídeo es el factor fundamental para la transmisión de vídeomediante un canal de comunicación con un coste aceptable. También es básica para la autoríamultimedia, el entretenimiento, los sistemas educacionales, la televisión digital por satélite, etc.Por otro lado, la historia de la tecnología de compresión está íntimamente relacionada con la his-toria de la industria de la videoconferencia. Por ejemplo, en una videoconferencia un CIF (Com-mon Intermediate Format), Formato Común de Intermediación, contendría 352 x 288 pixels deluminancia, 176 x 144 de crominancia R-Y y 176 x 144 de crominancia B-Y. A 30 frames enNTSC (25 en PAL) por segundo con 8 bits de información por píxel, esto es alrededor de 36 Mbpor segundo, y transmitirlos por un canal de comunicaciones RDSI (RDSI, Red Digital de Servi-cios Integrales en España) a 128 kb por segundo es un reto formidable. Pretenderlo en tiemporeal manteniendo la sincronización del audio y el video es todavía más difícil.

En la figura 10.1 se muestra un diagrama especialmente significativo, que ilustra cómo la historiade la videoconferencia está estrechamente relacionada con la historia de las tecnologías de com-presión y los desarrollos industriales relacionados con ella, tanto hardware como software.

TEMA 10. COMPRESIÓN DE VÍDEO UNED - CURSO 2007-2008

10.2 Tecnología de los Contenidos Multimedia

Figura 10.1 Necesidades de ancho de banda para el transporte de video a lo largo de los años.

Como puede observarse durante la década de los 80 se produjo un extraordinario descenso en losrequerimientos necesarios de ancho de banda para obtener una secuencia de video de calidadaceptable. Tras esta década, el ancho de banda necesario para la transmisión de video está alrede-dor de 1.5 Megabits por segundo. Hoy en día, la mayoría de los usuarios encuentran suficiente-mente satisfactoria una velocidad de 384KB por segundo, y se han producido mejorasextraordinariamente significativas tanto en los algoritmos como en las capacidades de los dispo-sitivos hardware diseñados para ejecutar dichos algoritmos.

Por otro lado durante este periodo de tiempo también se han desarrollado importantes mejoras enel precio y en la capacidad de las líneas de comunicación que han permitido transportar lassecuencias digitales de bits necesarias para conseguir calidades relativamente buenas tanto devideo como de videoconferencia.

Con todo ello puede establecerse que la convergencia entre la capacidad de las comunicacionescon la tecnología de compresión han permitido el desarrollo del video digital y la entrada masivade la industria y el consumo en este campo.

Con el fin de comprender el coste real de la compresión de video se analiza el siguiente ejemplo.Considérese la compresión del video NTSC, que es el estándar de las emisiones de televisión,VCR y videocámaras en USA. El estándar en Europa y Asia es PAL o C-CAM. En cualquiercaso el cálculo es el mismo salvo los datos.

Si se digitaliza una señal de video NTSC y cada frame se digitalizará. Como hay 30 frames porsegundo se tendría una secuencia de alrededor de 24.9 MB por segundo o 200 Megabits porsegundo:

• 1 frame = 720 x 576 pixels de luminancia + 2 x 360 x 576 pixels de crominancia• 1 frame = 829,440 bytes a 30 frames por segundo. • NTSC = 24.9 Mbytes / sec = 200 Mbits/sec

Anc

ho d

e B

anda

1970 1980 1990 2000

capacidad

1.5 Mbps

768 Mbps

Requerimientos


Tecnología de los Contenidos Multimedia 10.3

Es recomendable que el lector realice los cálculos para el sistema PAL con los datos indicados enel capítulo anterior.

Obviamente esto excede con mucho la capacidad de la mayoría de las líneas de comunicación.Por ejemplo la línea T1, que en general es considerada como un acceso a Internet de alta veloci-dad, sólo es capaz de transmitir 1.54 Mbits/sec. Puede observarse que la compresión es funda-mental, al igual que se indicó en el ejemplo anterior de la videoconferencia.

En conclusión, puede considerarse que típicamente es necesaria una compresión de 500, 1000 o2000 a 1 para que sea posible la transmisión de una secuencia de video mediante las líneas decomunicación disponibles. Es imprescindible comprimir la señal.

Análogamente sucede en la transmisión de vídeo con televisión de alta definición, o HDTV(High Definition TV). Un formato de vídeo HDTV habitual se escanea progresivamente con 7201280 pixels/frame, con una señal de vídeo a 60 frames por segundo, con 24 bits/píxel, 8 bits parael rojo, 8 para el verde y 8 para el azul, lo que implica una velocidad de datos por fila de alrede-dor 1.3 Gbits por segundo. Con las comunicaciones digitales modernas se pueden transmitircerca de 20 Mb por segundo con un ancho de banda de 6 MHz por cada canal de televisión. Denuevo se observa la necesidad de utilizar potentes técnicas de compresión para comprimir en estecaso con un factor de 70, equivalente a 0.35 bits/pixel, para enviar por un canal de 20 MB porsegundo la información con una velocidad de fila de 1.3 Gb por segundo. El estándar de compre-sión de vídeo MPEG-2 es el utilizado para la compresión de vídeo HDTV.

En conclusión la compresión de vídeo ha sido un instrumento esencial en diversas aplicaciones,entre las que destacan la televisión digital, los discos de vídeo digital, la telefonía con vídeo y lassecuencias de vídeo transportadas mediante Internet o enlaces sin cables (wireless). Además lacompresión ha sido un elemento crucial para superar el problema de la limitación en el ancho debanda, y también en la capacidad de almacenamiento.

10.2 COMPRESIÓN / DESCOMPRESIÓN: CARACTERÍSTICAS Y RESTRICCIONES.

La compresión y la descompresión se realiza mediante un codificador y un decodificador respec-tivamente, que en la terminología del área suele denominarse Codec. Este elemento no es másque una función, que toma una secuencia de bits y da como salida una secuencia de datos. Lafigura 10.2 muestra el esquema general de la tarea del Codec.

Existen diferentes Codecs ya que algunos se optimizan para audio, otros para video, voz o paradatos. Por otro lado debe tenerse en cuenta que hay multitud de restricciones en el diseño lo quetambién implica la existencia de multiples Codecs.

Prácticamente existen tantos CODECs para la compresión de audio y video como investigadoresen el área. Las elecciones posibles son múltiples y las aplicaciones son aún más.



Figura 10.2 Codec. Compresión / descompresión.

Otro aspecto de especial interés es el hecho de que un Codec es una función, y no está limitado aningún aspecto en particular, ni es un dispositivo en particular. Por ejemplo puede ser una simpletarjeta en un computador personal, o un chip en una placa madre, o una función software que seejecute en un computador.

Un primer aspecto a considerar es la compresión genérica multimedia. En general en los entornosmultimedia se hace uso de los conocimientos fisiológicos sobre los sistemas de visión y audiciónhumana. Esto es especialmente útil en el diseño de los Codecs que aprovechan las facultades másrelevantes de los sistemas auditivos. Por ejemplo, es conocido que el ojo humano es mucho mássensible al brillo y mucho menos sensible a la variación del color. Por ello en la compresión devideo se presta mucha más atención a los elementos que tratan el brillo y mucha menos a los decolor. Análogamente se conoce que el oído humano no puede oír algunas frecuencias y que otrasno son agradables de escuchar. Por ello las señales con estas frecuencias se digitalizan con menosprecisión o incluso se eliminan completamente en el proceso de compresión.

Tanto cuando se selecciona un Codec como cuando se diseña es fundamental considerar las res-tricciones. Como todo usuario de Internet sabe, en el entorno de las comunicaciones es muyimportante disponer de Codecs adecuados. Es importante realizar las comunicaciones sin que elusuario tenga que preocuparse de los detalles del hardware en cada extremo de la comunicación yes necesario que independientemente del esquema que se utilice en la compresión el otro lado dela comunicación pueda descomprimir. Sin embargo, las restricciones impiden que haya un únicoCodec universal.

Por ejemplo, en la compresión de video siempre existe una cuestión que debe tenerse en cuenta:cuántos bits por píxel se están suponiendo en la compresión. En el ejemplo de la compresiónNTSC anteriormente comentado se ha supuesto que hay 8 bits por píxel para los pixels de lumi-nancia y también 8 para los de crominancia. Sin embargo, si la capacidad de memoria es una res-tricción debería almacenarse todo en un byte.

CODECDatos de Entrada Datos de Salida

AudioVozVideoDatos

Restricciones de diseño



Una de las características principales de los Codecs es su complejidad computacional. Los algo-ritmos muy complejos pueden necesitar una potencia de cálculo que no está disponible en el sis-tema utilizado.

Es evidente la importancia de las restricciones en el diseño del Codec, pero la más importante esque el Codec pueda realizar su tarea con una complejidad computacional adecuada y adaptada ala potencia de cálculo disponible. Sería absurdo diseñar un Codec que necesite dos supercompu-tadoras tipo Cray o un clúster cuando la aplicación se desarrolló en el entorno de la informáticade consumo. Además es evidente que debe haber sintonía entre la potencia de cálculo y las exi-gencias del algoritmo. Por ejemplo los algoritmos de compresión de voz para telefonía sin cabledeben ejecutarse en procesadores de señal que sean compatibles con las características de la tec-nología sin cables (wireless), como por ejemplo un bajo consumo de potencia para conseguir unalarga vida de la batería.

Otra restricción importante para las trasmisiones en tiempo real es la razón de compresión, aun-que con frecuencia es una de las más ignoradas. Sin embargo es obvio que la salida del Codectiene que ser compatible con la capacidad del canal de comunicaciones. Por ejemplo, si se estátrabajando con un Codec MPEG2, no es posible que se transmita adecuadamente por un canal debajo coste en tiempo real ya que la salida del MPEG2 es de 6Mb por segundo, 6000 kb porsegundo. Esta es la velocidad de la televisión MPEG2 por satélite, mientras que la de por ejem-plo un CD-ROM I/O es 1.5 Mb/s (Mb=Megabits) por segundo en aplicaciones multimedia queno tiene mucha aplicación para los sistemas de comunicación basados en la telefonía (que dispo-nen de 9.6 a 128 kb por segundo). Por tanto es evidente que un Codec optimizado para el anchode banda de la televisión MPEG2 por satélite ofrece mayor calidad de audio y video que unooptimizado para videoconferencia sobre línea RDSI a 128 kb por segundo.

La restricción más evidente es que la calidad de la salida del Codec debe ser aceptable. Sinembargo, esta restricción es ignorada con frecuencia, a costa del sufrido observador del resul-tado. Si se trata de comunicaciones y transmisión de voz es evidente que el Codec sólo será ade-cuado si lo escuchado es inteligible y el hablante reconocible, y lo mismo sucede en lacodificación de video, aunque es habitual que en las videoconferencias las deficiencias en lasalida no sean fuertemente rechazadas por el usuario. Afortunadamente la calidad es un factorque se beneficia de las continuas mejoras que se realizan tanto en los algoritmos como en lapotencia de cálculo.

Otro aspecto a considerar es la simetría. En el entorno de las comunicaciones bidireccionales entiempo real, los usuarios suelen enviar y recibir secuencias simultáneamente a ambos lados de lalínea de codificación, piénsese por ejemplo en la videoconferencia. Esta es una situación muydiferente al paradigma típico de los desarrollos multimedia sobre PC. Por ello en estas aplicacio-nes es necesario que el Codec realice la compresión y la descompresión de forma balanceada, esdecir, utilice el mismo tiempo para realizar la compresión y la descompresión. Evidentementeeste aspecto no tiene interés en las aplicaciones unidireccionales, en las que se almacenan las



secuencias de salida del Codec y posteriormente se envían. Además, los algoritmos basados en elmodelo consistente en codificar una vez lentamente y decodificar muchas veces rápidamente noson apropiados para la videoconferencia. Sin embargo, los algoritmos con simplicidad suficientepara descodificar pueden implementarse en un host PC, mientras que la codificación normal-mente se realiza sobre dispositivos dedicados o DSP de propósito general. Este hecho también seestá convirtiendo cada vez más en un paradigma para los MPEG multimedia.

Un factor importante a tener en cuenta es la latencia. La latencia es un término técnico que indicaretardo o retraso, relacionado con el manejo de los bits de forma agrupada. Si se agrupa unamuestra grande de datos y se comprime se pueden analizar los datos y tratarlos con un algoritmopara comprimir un grupo de datos. Hacer esto es mucho más eficiente que tratar cada punto indi-vidualmente, obsérvese que por ejemplo se pueden evitar redundancias. Sin embargo al agruparun grupo de datos normalmente aparece un gran retardo debido al tiempo utilizado para agruparlos datos. Por ejemplo, si se agrupan 30 milisegundos de datos de voz y posteriormente se decidecómo comprimirlos se está introduciendo al menos un retardo de 30 milisegundos en el lado de larecepción y otros 30 milisegundos en el de la emisión. Por tanto, en una comunicación en tiemporeal se están introduciendo al menos 60 milisegundos, lo que es muy significativo en los entornosde comunicación bidireccionales en tiempo real. Cuando se tienen diferentes cantidades deretardo en el video y en el audio se empieza a perder la sincronización, lo que es molesto einaceptable. Por tanto la latencia es un problema serio en las aplicaciones de videoconferenciapero no es un problema para las que utilizan almacenamiento para la posterior comunicación,como por ejemplo las películas en DVD.

Hay aplicaciones, especialmente en la compresión de datos, en las que es muy importante dispo-ner de un entorno "sin pérdidas", lossless, es decir, es importante que al descomprimir los datosse obtenga una reproducción exacta de la señal original.

La compresión sin pérdidas se considera un proceso reversible en el que se puede reconstruir per-fectamente la secuencia de datos de imágenes o audio. Ejemplos de esta característica son las téc-nicas de codificación vectorial, codificación de entropía o codificación de longitud variable(como los códigos de Huffman).

La compresión con pérdidas hace uso de las características fisiológicas y especialmente los lími-tes de los sistemas sensoriales humanos, que permiten eliminar de las secuencias de datos señalesde varias frecuencias y amplitudes no detectables.

La codificación psicofísica produce técnicas de compresión que reducen el número de bits nece-sarios para reproducir los sonidos o imágenes, pero la reconstrucción nunca es el 100% del origi-nal. Evidentemente las técnicas sin pérdidas serían inapropiadas para la compresión de datoscuando cada bit cuenta, como por ejemplo en bases de datos en las que cada bit es importante oen la transmisión de imágenes médicas.

Las técnicas de compresión sin pérdidas están muy limitadas, en general a una razón de compre-sión de 4 a 1, mientras que las técnicas con pérdidas pueden ofrecer razones de 200 a 1.



Por último una restricción evidente es el coste. Cuando se elige un Codec es importante conside-rar los costes tanto de software como de hardware. Cualquier algoritmo de compresión de videorepresenta un compromiso de diseño entre la potencia de cálculo requerida para implementar lacompresión, la potencia de cálculo necesaria para la descompresión, la calidad de los datos des-comprimidos en relación con los datos de entrada, la razón de compresión y el retardo debido alesquema de compresión. Por ejemplo, la razón de compresión más alta posible se obtendría conun coste de hardware elevado o si no se tendría una muy pobre calidad de imagen en el receptor.

Sin embargo, como el coste de un equipo es un factor determinante obtener la mayor compresiónde los datos de vídeo posible con la mayor calidad de vídeo no es una solución adecuada, por loel mercado presenta una amplia gama de posibilidades que serán más o menos adecuadas en fun-ción de la aplicación que vaya a ser desarrollada en las mismas.

Para la videoconferencia corporativa la selección de un esquema de compresión con una calidadde imagen razonable pero no grande es menos sensible al precio que una aplicación de juegosmultimedia, en la que el coste es fundamental. El punto clave en la videoconferencia es un algo-ritmo de compresión que produzca una secuencia con velocidad compatible con el canal decomunicación. Y además, como se ha dicho, la compresión debe tener latencia pequeña paramantener la sincronización y que la comunicación sea en vivo.

Sin embargo, para los reproductores de CD-ROM el objetivo principal es que la descompresiónsea de bajo coste, que suele conseguirse utilizando sólo software, que puede producir videobasándose en velocidades de datos fuera del reproductor de CD-ROM. Como el material se com-prime sólo una vez, el tiempo y el coste de la compresión no son aspectos primordiales. Lomismo ocurre en la distribución de video por demanda, se comprime sólo una vez y se trasmitepor cable o satélite, descomprimiéndose finalmente en el receptor.

10.3 TÉCNICAS DE COMPRESIÓN

El esquema general de compresión de vídeo consta de tres pasos básicos:

1.- Análisis de la señal.Se realizan medidas sobre la secuencia de vídeo de entrada, se calculan los errores de pre-dicción y se realizan las transformadas (operaciones matemáticas) del dominio temporal aldominio de la frecuencia, obteniendo los coeficientes asociados a dicha transformada. Lacompresión de datos siempre se realiza haciendo uso de un algoritmo de procesamientodigital de señales. Seguidamente se divide la señal en subbandas y se realiza un análisis decorrelación. Los pixels de entrada se transforman a otro formato, por ejemplo a los coefi-cientes de la transformada discreta del coseno, DCT, pero estos mantienen toda la informa-ción de la señal, salvo errores de redondeo, por lo que no se realiza ninguna reducción dedatos.



2.- CuantificaciónEn este paso es dónde se realizan la mayoría de las técnicas de compresión porque el cuanti-ficador puede eliminar valores que representan información inútil. Este paso suele implicarpérdidas en la información para recuperar la señal, pero también se pueden definir técnicassin pérdidas con razones de compresión menores.

3.- Codificación de longitud variable o codificación por entropía.A cada evento se le asigna un código con un número de bits variable. En general sucedeneventos que tienen códigos con pocos bits, sólo los eventos poco comunes tienen códigoscon muchos bits. Es de esperar que la longitud de código en promedio sea menor que la lon-gitud de un código fijo que sería necesario sin esta disposición. Esto suele realizarsemediante el código de Huffman.

En general pueden considerarse dos aproximaciones para implementar un Codec. El primero seconoce como Procesamiento de Señal Nativo, Native Signal Processing. Generalmente estábasado en un Host en el que se utiliza un procesador, como por ejemplo un Pentium, una SunSpark Station o un procesador HP, con un Codec software. La característica básica en este tipo decompresión es que el procesador es de propósito general y el Codec es sólo software, lo que per-mite que sea una implementación de bajo coste y la integración y el desarrollo del software esmás general y sencillo.

La segunda aproximación es utilizar un dispositivo dedicado, típicamente un chip que ha sidodiseñado y optimizado para la compresión de video y/o audio. Estos chips son conocidos comoProcesadores Digital de Señales, DSP (Digital Signal Processors), y ofrecen prestaciones muchomayores. Además libera a la CPU de la tarea de compresión, por lo que puede ejecutar otras apli-caciones, y es compatible con dispositivos no conectados e individuales.

Las tecnologías utilizadas para la compresión de video son muy diversas pero en general puedenestablecerse cuatro aproximaciones para implementar la compresión de un frame de video:

• Transformada del Coseno Discreta, (DCT, Discrete Cosine Transformation).• Cuantificación vectorial, (VQ, vector quantization).• Compresión fractal.• Transformada Wavelet Discreta, (DWT, Discrete Wavelet Transform)

La DCT es la base fundamental para la mayoría de los protocolos de comunicación y también lamayoría de los estándares que se utilizan hoy en día, como por ejemplo JPEG 2000, MPEG-1 yMPEG-2, H.26X, y prácticamente todos los sistemas de videoconferencia. Durante el proceso decodificación basada en DCT una imagen se divide en bloques de 8 8 pixels que serán la entradade la DCT, en la que se reducen las redundancias. Seguidamente se realiza la cuantificación utili-zando funciones con peso optimizadas para el sistema visual del ojo humano. Como la visiónhumana es menos sensible al color que al brillo, la gradación de niveles en la cuantificación delos valores de color pueden ser mayores que la de los valores de intensidad, es decir, la distanciaentre los niveles de los valores cuantificados puede ser mayor. Esto permite un mayor grado de



compresión para los componentes de color sin provocar una degradación perceptible de la ima-gen. Análogamente, como la visión humana es menos sensible a los detalles de alta frecuencia(variaciones rápidas) que a los de baja frecuencia (variaciones lentas), la cuantificación de losvalores de alta frecuencia puede ser mayor, obteniéndose una compresión extra sin deteriorar sig-nificativamente la calidad de la imagen.

Como se comprime a lo largo de todo el rango de datos la operación de cuantificación sobre lamatriz de frecuencias resultante de la DCT se convertirá en una matriz alterada que contienemuchos valores iguales debido a la cuantificación. En particular una matriz cuantificada contienemuchos más ceros. La matriz cuantificada puede tratarse de manera inversa para recuperar deforma aproximada la original, pero siempre habrá pérdidas de mayor o menor importancia enfunción del tamaño de la granularidad de la cuantificación.

Finalmente los datos resultantes de la cuantificación se codifican en entropía utilizando unesquema de Huffman de longitud variable. Para descomprimir la imagen se realiza el procesoinverso. El esquema general de la compresión con DCT directa se ilustra en la figura 10.3.

Figura 10.3 Esquema general de la codificación con DCT directa.

Estas técnicas de compresión se aplican sobre un único bloque de datos, por lo que se denominanintrabloques. En ningún caso consideran los datos que no estén en el bloque tratado. En generalcon estas técnicas de compresión pueden obtenerse razones de compresión de 20 a 1 o 30 a 1.

En la codificación vectorial los cambios en la posición de un píxel se representan mediantenúmeros que indican la magnitud y la dirección. La VQ elimina menos información sobre losdatos de color que la DCT, pero tiende a difuminar movimiento en los laterales de una imagenque se mueve rápidamente. Con VQ una palabra digital transmitida representa los valores cuanti-ficados de más de una muestras de la señal. Para imágenes, un único vector normalmente repre-senta un array de 4 4 pixels. VQ es un algoritmo altamente asimétrico. La codificación necesitaun proceso complejo de búsqueda para determinar qué vector se transmite y la decodificaciónconsiste meramente en utilizar una tabla de consulta para dibujar el valor correspondiente.

Las tecnologías con fractales y wavelets se basan en técnicas avanzadas en el procesamiento deseñales digitales. Las wavelets descomponen una imagen en componentes frecuencialesmediante un filtrado iterativo paso baja y paso alta que se realiza sobre la imagen completa, no en

DCT hacia delante Cuantifucador Codificador de

EntropíaDatos de la imagen

comprimida

Tabla de especificaciones

Tabla de especificaciones

Datos de imagenoriginal

bloques 8x8



bloques. El resultado es una representación jerárquica de la imagen en la que cada capa repre-senta una banda de frecuencia.

La compresión fractal es lenta debido a su complejidad, pero produce una tamaño de ficheromucho menor que con otras técnicas, y la descompresión puede realizarse con software. Laempresa Iterated Systems, Inc ha apostado fuerte por la tecnología fractal y desarrolla tecnologíapara la compresión de imágenes de calidad desde CD-ROM. Esta empresa también es muy activaen la distribución de vídeo a través de Internet y está desarrollando tecnología para videoconfe-rencias bidireccionales.

Por otro lado Aware Inc., promociona las wavelets como una forma de mejorar la calidad de lacompresión de vídeo, y tiene licenciada la mayoría de su tecnología a Analog Devices, que estambién líder en el campo de las wavelets. Al contrario que la DCT, la DWT, se aplica sobre laimagen completa, eliminando con ello los efectos debidos a la partición en bloques, típicos de lastecnologías basadas en DCT.

Además de la clasificación de la compresión de video en cuatro tipos que se acaba de describir,suele establecerse que existen dos tipos de aproximaciones al problema de la compresión devídeo, de acuerdo con el hecho de que se base en datos de un único frame o no. Si la técnica sebasa en los datos de un único frame se conocen como intraframes. Un ejemplo típico de estándarbasado en intraframes es el JPEG. Mientras que si se obtiene compresión adicional mediante lacomparación de varios frames se denomina interframe. Las técnicas interframe aprovechan lassimilitudes (redundancia) que existe entre frames adyacentes.

Si se quieren conseguir razones de compresión mayores manteniendo una calidad aceptable lamayoría de los dispositivos de compresión utilizan técnicas interbloques, que utilizan informa-ción de otros bloques realizando comparaciones bloque a bloque. Una aproximación interbloquessencilla consiste en calcular la diferencia entre dos bloques adyacentes y comprimir y transmitirsólo la diferencia. Por ejemplo puede restarse el bloque 15 del 16 y comprimir la diferencia, yaque no es de esperar que las diferencias sean muy grandes entre los datos de un bloque y elsiguiente. De hecho se espera que haya un gran numero de ceros tras la resta, y los ceros son fáci-les de comprimir. Por tanto, si se realizan comparaciones bloque a bloque hay un gran número detécnicas de estimación y de compensación de movimiento que permiten deducir cómo se hapodido mover el frame, por ejemplo desplazado cuatro pixels a la derecha y hacia arriba tres. Enconsecuencia, se está enviando al receptor por el canal de comunicación cómo desplazar la ima-gen anterior. Como puede imaginarse estas técnicas se caracterizan por una gran capacidad decompresión, es decir, razones de compresión mucho mayores. El coste de esta mejora se encuen-tra en el hecho de que los algoritmos son mucho más complejos y necesitan más recursos de cál-culo.

La figura 10.4 muestra que con compresión intrabloques se eliminan redundancias con un únicoframe, mientras que la compresión interframe elimina redundancias entre frames adyacentes.



Figura 10.4 Compresión intraframe e interframe.

Mapa debits RGB

Traducciónal espacio de colo

YUV

Azul

VerdeRojo

Luminancia

Crominancia

Tranformadaal dominio dela frecuencia

Cuantización

CodificaciónRun lenght

CodificaciónHuffman

Compresión intraframe

Frame actualFrame anterior

Compresión interframe

Cambios

Las diferencias representanel frame completo

Dispositivos de comparación



Hoy en día existen soluciones que permiten codificar y descodificar mediante software y hard-ware en diversas combinaciones: codificación y descodificación hardware, ambas software o unahardware y la otra software. Además hay soluciones que utilizan una de estas tres aproximacio-nes para el audio y otra diferente para el video. Todas ellas coexisten en el mercado.

En la figura 10.5se muestra la relación entre calidad y número de bits por píxel con las técnicasde compensación de movimiento. Como puede observarse con una técnica determinada, paramejorar la calidad de imagen tiene que aumentarse el número de bits por píxel. Pero se puedeaumentar la calidad de la imagen con un número fijo de bits por píxel si se utilizan técnicas decompresión interbloques cada vez más y más complejas.

Figura 10.5 Relación entre calidad y número de bits por píxel con las técnicas de compensación de movimiento.

10.4 ESTÁNDARES DE COMPRESIÓN DE VIDEO

Los estándares de compresión de vídeo proporcionan un gran número de ventajas, siendo la másimportante el hecho de que facilitan la interoperabilidad. Asegurar la interoperabilidad permiteque los riegos de tener un sistema de poco uso, tanto para los consumidores como para los fabri-cantes, sean los menores posibles, ya que permiten comunicación entre dispositivos diseñadospor diferentes fabricantes. Los estándares permiten una aceptación más rápida de los productosasí como un uso más amplio. Además se diseñan para un gran número de aplicaciones, por lo quese reducen costes debido a la economía de escala.

Actualmente existen dos familias de estándares de compresión de vídeo, definidos bajo los auspi-cios de dos organizaciones internacionales. Por un lado la ITU-T, International Telecommunica-tions Union- Telecommunications, antes conocida como International Telegraph and TelephoneConsultative Committee, o CCITT, y en segundo lugar la ISO, International Standards Organiza-tion.

Algoritmo de futuro movimientocompensado

Compresión de movimientocompensado

Compresión de imagenestática

Número de bits/pìxel

Calidad dela imagen



El primer estándar de compresión de vídeo que consiguió una muy amplia aceptación fue el ITUH.261, que fue diseñado para la transmisión de videoconferencia sobre la red de servicios digita-les integrados, RDSI. El H.261 fue adoptado como estándar en 1990, y fue diseñado para funcio-nar a velocidades con múltiplos p=1, 2,..., 30 de la velocidad de datos de la línea base RDSI, esdecir, a p 64 kb por segundo.

En 1993, la ITU-T inició un esfuerzo de estandarización en la que el primer objetivo era la telefo-nía con vídeo sobre la red pública de telefonía conmutada, PSTN en USA (Public Switched Tele-phone Network), RTB en España (Red Telefónica Básica). Estas redes son líneas telefónicasanalógicas convencionales, en las que la capacidad total en la velocidad de datos es sólo de 33.6kb por segundo. La parte del estándar referente a la compresión de vídeo se denomina H.263, ysu primera fase fue adoptada en 1996. Una versión H.263 realzada, conocida como H.263+, fina-lizó en 1997. En la actualidad se está desarrollando un nuevo estándar de compresión conocidocomo H.26L.

Existen numerosos estándares para los Codecs publicados por la ITU-T, y además de los comen-tados cabe destacar las técnicas de compresión H.261 para video y la G.728 para audio.

El grupo de expertos conocido como MPEG, (Moving Pictures Expert Group), fue establecidopor la ISO en 1988 con el fin de establecer un estándar para la compresión de imágenes en movi-miento y el audio asociado a medios de almacenamiento digitales tales como CD-ROM. Esestándar que resultó inicialmente, conocido como MPEG-1, finalizó en 1991. Este proporcionaaproximadamente calidad de vídeo VHS y audio con alrededor de 1.5 Mb por segundo. Lasegunda fase de su trabajo desarrolló el siguiente compresor, denominado MPEG-2, que era unaextensión del MPEG-1 desarrollada para la emisión de televisión digital y con velocidades de bitmayores.

Actualmente la mayoría de los estándares de televisión digital, DTV, y de televisión digital dealta definición, HDTV, se basan en la tecnología MPEG-2 tanto en Norte América y Europacomo en Asia.

Recientemente ha finalizado la tercera fase del trabajo de este grupo de estandarización, desarro-llando el estándar conocido como MPEG-4. El objetivo fundamental del MPEG-4 es proporcio-nar una funcionalidad creciente, incluyendo procesamiento basado en contenido, integracióntanto natural como sintética, material generado por computador e interactividad con la escena.

La tabla 10.1 muestra los estándares de compresión más habituales con sus aplicaciones caracte-rísticas y la velocidad de bits que son capaces de desarrollarse con cada tecnología.

El bitrate, tasa de bits o velocidad de bits especifica únicamente el número de bits por segundoque tiene una secuencia. Si disminuye a valores muy pequeños, se tienen muy pocos bits porframe. Esto hace que al reproducir el video sea evidente esa pérdida de información y se obtengauna imagen degradada. Así pues ajustando la velocidad de bits se determina cuántos bits por



segundo se utilizan para almacenar la información. Esto a su vez determina la perdida de infor-mación y con ello la calidad de la imagen.

Tabla 10.1 Estándares de compresión más habituales con sus aplicaciones características y la velocidad de bit.

Los fabricantes que utilizan los Codecs basados en estándar son probablemente los que disfrutande mejor interoperatividad. Sin embargo, los algoritmos de propietario pueden ofrecer ventajasen determinadas situaciones. Si la necesidad de interoperatividad o de soportar contenidos deotros fabricantes es mínima entonces tiene el sentido para el diseñador utilizar un algoritmo decompresión de propietario. Algunos algoritmos son estándares de hecho debido a su amplia utili-zación por los usuarios y por estar disponibles a muy bajo coste, y sin embargo nunca han sidoestandarizados oficialmente.

Una cuestión muy importante es qué especifica realmente un estándar de compresión de vídeo.Esto permitirá además de conocer cuál es su aplicación fundamental, de qué manera es compati-ble con otros sistemas u otras tecnologías desarrolladas para la misma o diferente aplicación. Engeneral, un sistema de compresión de vídeo está formado por un codificador, secuencias de bitscomprimidas y un decodificador. El codificador recibe la señal de vídeo original y la comprimeen una secuencia de bits. Está secuencia entrará en el decodificador que realizará el procesoinverso para reconstruir el vídeo original. La figura 10.6 muestra este esquema básico.

Figura 10.6 Esquema básico de una especificación del estándar.

Una posibilidad para definir un estándar es que este especifique tanto el codificador como eldecodificador, pero esta aproximación tendría un gran número de desventajas, todas ellas relacio-nadas con el hecho de que el detalle de estos elementos provocaría que cualquier pequeña modi-ficación no fuera compatible, incluso cuando se pudieran conseguir los mismos resultados. Enlugar de ello, los estándares delimitan las características que especifican con el fin de asegurar la

ESTANDARD APLICACION BIT RATE JPEG Compresión de imágenes tonos continuos Variable

H.261 Telefonía de vídeo y teleconferencia sobre RDSI

p x 64 kb/s p=1, 2,…,30

MPEG-1 Vídeo sobre medios de almacenamiento digital (CD-ROM) 1.5 Mb/s

MPEG-2 Televisión Digital. DVD > 2 Mb/s H.263 Telefonía de vídeo sobre RTB < 33.6 kb/s

MPEG-4 Codificación basada en objetos, contenido sintético, interactividad Variable

VídeoOriginal

Codificador DecodificadorBits-streamSecuencia de bits

VideoReconstruido



interoperabilidad a la vez que permiten que en las implementaciones concretas haya diferenciasen la medida de lo posible.

En concreto, los estándares no especifican ni el codificador ni el decodificador, tal y como ilustrala figura 10.7. En lugar de ello especifican la sintaxis de la secuencia de bits y el proceso dedecodificación. La sintaxis de la secuencia de bits es el formato en el que se representan los datoscomprimidos. El proceso de decodificación es el conjunto de reglas o técnicas que permiteninterpretar la secuencia de datos.

Figura 10.7 Especificaciones de los estándares.

Aparentemente este hecho es igual a especificar el decodificador, pero no es así. Obsérvese queel especificar el proceso de decodificación es diferente a especificar una implementación particu-lar de un decodificador. Por ejemplo, el estándar puede especificar que el decodificador utilizauna transformada IDCT, pero no indica nada sobre como implementarla. La IDCT puede imple-mentarse de diferentes maneras. Así por ejemplo puede implementarse de forma directa omediante una transformada rápida de Fourier, FFT, o utilizando instrucciones MMX. En estecaso, la elección de la implementación tendrá como consecuencia un mayor o menor coste com-putacional lo que repercutirá en un mayor o menor tiempo para realizar la descodificación, o unamayor o menor precisión en el cálculo, pero no afecta al estándar. La especificación de la imple-mentación no estaría estandarizada. Esto permite a los diferentes diseñadores y fabricantes desa-rrollar sus tecnologías de manera diferente dentro del mismo estándar.

El proceso de codificación tampoco se estandariza. Por ejemplo, pueden diseñarse los codifica-dores más sofisticados para proporcionar mejoras significativas en las especificaciones de loscodificadores básicos.

Además, un aspecto fundamental que resulta una extraordinaria ventaja debida a que no se espe-cifica en la estandarización ni el codificador ni el decodificador es que pueden incorporarse lasmejoras que se van desarrollando sobre los algoritmos, incluso cuando el proceso de estandariza-ción ha finalizado y el estándar está completamente definido. Por ejemplo, las mejoras realiza-das en los algoritmos y en las técnicas de estimación o compensación de movimiento o para lalocalización de bits pueden irse incorporando y se podrán incorporar en el futuro de forma com-patible con los estándar ya establecidos. La única limitación es que el codificador produzca unasecuencia de bits sintácticamente correcta de manera que pueda ser descodificada de forma apro-

Proceso de decodificación

Ámbito de la estandarización



piada por cualquier decodificador compatible con el estándar. En conclusión, es importanterecordar que no todos los codificadores y decodificadores de un estándar determinado son igua-les.

A continuación se describirán las técnicas más significativas de la compresión de vídeo. Pero engeneral la compresión se obtiene explotando las similitudes o correlaciones que existen en unseñal de vídeo típica. Esto puede entenderse como una reducción de la redundancia que se da enlos datos de vídeo. Existen tres clases de redundancia básicas:

• Redundancia Temporal. Se debe a frames adyacentes altamente correlacionados.• Redundancia Espacial. Los pixels cercanos suelen estar correlacionados. • Redundancia espacial de color. Los componentes RGB se correlacionan entre sí.

La redundancia temporal se basa en el hecho de que a menudo los frames consecutivos en unasecuencia de vídeo están altamente correlacionados, ya que en general contienen los mismosobjetos. Es probable que de un frame al siguiente lo que se ha producido es algún tipo de movi-miento, un desplazamiento hacía la derecha y hacia arriba, por ejemplo. Los datos son esencial-mente los mismos pero desplazados.

La redundancia espacial se encuentra generalmente en un mismo frame, ya que las amplitudes delos pixels cercanos están a menudo correlacionadas.

Por último la redundancia espacial de color hace referencia al hecho de que a menudo estáncorrelacionadas las componentes del color, rojo, verde y azul, de los pixels.

Normalmente la redundancia es un hecho que puede ser identificado y explotado para la compre-sión.

La segunda característica en la que se basa la compresión de vídeo es la irrelevancia en la señalde vídeo, fenómeno que consiste en reducir la información que no es perceptualmente impor-tante, o que de hecho no será percibida por los aparatos sensoriales humanos. Desgraciadamentela percepción visual humana es muy difícil de modelar, por lo que determinar qué datos son pre-ceptualmente irrelevantes es una tarea difícil, por lo que la irrelevancia es difícil de explotar. Dehecho sólo los algoritmos más avanzados y los estándares de mayores prestaciones hacen uso deesta característica.

Antes de analizar las técnicas básicas de compresión de vídeo es recomendable recordar breve-mente cómo se comprimen las imágenes. Para ello se analiza cómo funciona el estándar JPEG.

• Estándar JPEG (imágenes)

JPEG es una sencilla técnica de compresión intrabloque y se utiliza para las imágenes estáticas,como por ejemplo fotografías. Si se dispone de potencia de cálculo suficiente para realizar elalgoritmo JPEG 25 veces por segundo, entonces a menudo se denomina JPEG motion (MJPEG).

Como se acaba de comentar una imagen, o un frame de vídeo, contiene a menudo redundanciaespacial significativa ya que los bits cercanos son frecuentemente muy similares. Las imágenesen la naturaleza son normalmente de contenidos paso baja (de variación suave), y los algoritmos



de compresión de imágenes, como el JPEG, basan sus técnicas de compresión en la redundanciaespacial y la naturaleza paso baja de las imágenes típicas.

En el estándar JPEG la imagen se divide en primer lugar en bloques de 8 8 pixels. Seguidamentepara cada bloque se calcula la transformada discreta del coseno, DCT. La razón para dividir unaimagen en bloques pequeños es que en general los pixels de un bloque pequeño serán más simila-res que los que estén en un bloque grande.

La transformada DCT compacta la mayoría de la energía de la señal de cada bloque en sólo unafracción de coeficientes de la DCT. Entonces la cuantificación de los coeficientes DCT conducea que la mayoría de ellos sean cero. Los coeficientes cuantificados son seguidamente escaneadosen zigzag, codificados en longitud y esta codificación con los valores de las amplitudes son codi-ficadas con el código de Huffman para convertirlos en una secuencia de bits comprimida.

En el caso de una imagen en color se aplica la conversión del espacio de color antes de calcular laDCT. Esta conversión del espacio de color convierte la imagen RGB en un espacio de colordeterminado por la luminancia y la cominancia, en el que pueden explotarse mejor la diferentepercepción visual humana a las características de luminancia y cromarismo.

En resumen la compresión JPEG realiza las siguientes operaciones:• Dividir la imagen en bloques de 8 8 pixels.• Calcular la transformada DCT de cada bloque.• Cuantificar los coeficientes de la transformada DCT.• Codificar con el código de Huffman los coeficientes DCT cuantificados no nulos.

La figura 10.8 muestra el esquema básico del estándar de compresión JPEG.

Figura 10.8 Esquema básico del estándar de compresión JPEG de una imagen.

10.5 PRINCIPIOS BÁSICOS DE LA COMPRESIÓN DE VÍDEO.

Una secuencia de vídeo está formada por una secuencia de frames de vídeo o imágenes. Cadaframe puede codificarse como un paquete separado, por ejemplo aplicando independientemente acada frame una codificación del tipo JPEG. Sin embargo, el vídeo tiene la característica de quelos frames cercanos a un frame de vídeo son usualmente muy similares. La compresión de vídeopuede obtener razones de compresión mucho mayores que la compresión de imágenes explo-tando la redundancia temporal o las similitudes entre frames.

ImagenOriginal

DCT

Bitsteam

Cuantizador Codificador



El hecho de que los frames cercanos entre sí sean habitualmente muy similares puede explotarsecodificando un frame determinado prediciéndolo en primer lugar, tomando como base un framecodificado previamente y posteriormente codificando el error de predicción.

Los tres tipos básicos de codificación de frames son los siguientes:• I-frames. Son frames intracodificados (I), es decir, son frames que se codifican independiente-

mente de los otros frames.• P-frames. Son frames codificados previamente. En ellos el frame se codifica tomando como base

un frame previamente codificado.• B-frames. Son frames predichos bidireccionalmente. Estos frames se codifican utilizando los fra-

mes tanto anteriores como posteriores.

La figura 10.9 ilustra los tres tipos básicos de codificación de frames.

Figura 10.9 Los tres tipos básicos de codificación de frames: I-frame, P-frame y B-frame.

Las técnicas de predicción de la compensación de movimiento, P-frames y B-frames, se funda-mentan en las mismas ideas básicas, aunque posiblemente en diferentes localizaciones espacia-les. Para aprovechar la capacidad de predicción entre frames cercanos y vecinos es importanteestimar el movimiento entre dos frames y posteriormente construir una predicción apropiada quecompense el movimiento producido.

El proceso de estimación del movimiento entre frames se conoce como estimación del movi-miento. El proceso de predicción de un frame determinado se basa en un frame de referenciacodificado anteriormente, mientras que la compensación para los movimientos relativos entredos frames se conoce como predicción de movimiento compensado.

Figura 10.10 Ejemplos de predicción de movimiento compensado. a) hacia delante, P-frames b) bidireccional, B-frames.

Frame Anterior Frame Siguiente



La predicción de movimiento compensado basada en bloques se utiliza frecuentemente debido aque proporciona buenas especificaciones y tiene una estructura básica periódica que simplificalas implementaciones.

La figura 10.10 muestra ejemplos de predicción de movimiento compensado hacia delante en lafigura 10.10.a y bidireccional en la figura 10.10.b.

El frame tratado para ser codificado se divide en bloques de 16×16 pixels.

Para cada bloque en el frame a tratar se construye una predicción, y se busca el bloque que mejorse acopla, el más parecido, de los que han sido codificados previamente en el frame de referen-cia. El desplazamiento o movimiento relativo para el bloque que mejor se acopla es conocidocomo vector de movimiento. La arquitectura básica de la compresión de vídeo es la siguiente.

Los estándares de compresión de vídeo actuales obtienen la compresión aplicando los mismosprincipios básicos. La redundancia temporal se explota aplicando la predicción MC (MotionCompensation) mientras que la redundancia espacial se explota aplicando la DCT. La redundan-cia espacial de color se explota mediante la conversión del espacio de color. Los coeficientes dela transformada DCT se cuantifican y los coeficientes cuantificados no nulos se codificanmediante el código de Huffman para producir la secuencia de bits comprimida.

Figura 10.11 Esquema genérico de alto nivel de un codificador de vídeo.

RGBa

YUVDCT Cuantizador Codificación

Huffman

+

- Buffer

Señal deVídeo deEntrada

Residuo Bitstreamde salida

Cuantizadorinverso

DCTinversa

Datos MV

Compensaciónde movimiento

Estimación de

movimiento

Datos MV

Predicción

Frame PrevioReconstruido



El esquema genérico de alto nivel de un codificador de vídeo se ilustra en la figura 10.11. Comose comentó anteriormente los diversos estándares de vídeo especifican la sintaxis de la secuenciade bits y el proceso de descodificación, pero no especifica el proceso de codificación ni la imple-mentación del codificador. Por ello debe tenerse en cuenta que los esquemas genéricos sólodeben entenderse como ejemplos de codificadores o decodificadores típicos de un sistema decompresión de vídeo.

En el codificador la señal de entrada RGB se transforma en primer lugar en un espacio de colordeterminado por la luminancia y el cromatismo, conocido como YUV, con el fin de explotar laredundancia en el espacio de color.

Para explotar la redundancia temporal se utilizan la estimación de movimiento y la predicción dela compensación de movimiento, con el fin de construir una predicción del frame que se está tra-tando a partir de un frame previamente codificado.

El error de predicción, o residuo, se divide en bloques de 8×8 pixels y se calcula la 2-D DCT paracada bloque. Los coeficientes de la transformada DCT se cuantifican de forma adaptativa paraexplotar las características locales del vídeo y las de la percepción humana. Los coeficientescuantificados y otra información se codifican con el código de Huffman para aumentar la eficien-cia. A menudo se utiliza un búfer para acoplar al canal de comunicación utilizado y la velocidadde los bits de salida de vídeo del codificador, que es variable. Esto se consigue mediante unmecanismo de control de almacenamiento en el que se controla la ocupación del búfer en funciónde los coeficientes de cuantificación, regulando por tanto la velocidad de bits.

La figura 10.12 muestra el esquema genérico de alto nivel de un decodificador de vídeo

Figura 10.12 Esquema genérico de alto nivel de un decodificador de vídeo.

El proceso de decodificación de vídeo es evidentemente el inverso al proceso de codificación. Lasecuencia de bits se analiza y se realiza la descodificación de Huffman. Los coeficientes no nulosde la transformada DCT se identifican y se realiza la cuantificación inversa. Seguidamente serealiza una transformada inversa DCT del bloque que produce la señal residual, que se combinaespacialmente de una forma adaptativa con el frame reconstruido previamente con el objetivo dereconstruir el frame que se está tratando.

DecodificadorHuffman

Cuantizadorinverso

DCTinversa +Buffer

Bitstreamde entrada

Compensación demovimeinto

Datos MV

DCTinversa

Residuo

Predicción Señal de vídeode salida

Framereconstruido



Finalmente el frame reconstruido se reconvierte al espacio de color RGB para producir la señalde salida de vídeo.

Los estándar de compresión de vídeo actuales se fundamentan en la misma construcción de blo-ques básica, que incluyen predicción de movimiento compensado, DCT, cuantificación escalar,codificación de Huffmann,... Las especificaciones adicionales que se incorporan para aplicacio-nes particulares incluyen entre otras la capacidad de codificar vídeo entrelazado y herramientaspara flexibilizar los errores o para la escalabilidad.

La diferencia principal entre los estándares de compresión de vídeo radica en el hecho de que losestándares iniciales, incluyendo H.261, H.263, MPEG-1, y MPEG-2, utilizaban codificaciónbasada en frames. En concreto, estos estándares analizan cada frame como un grupo rectangularde pixels y codifican estos pixels utilizando predicción de compensación de movimiento basadaen bloques y transformada DCT de bloque. Efectivamente, estos estándares modelaban el vídeocomo si estuviera compuesto de bloques rectangulares en movimiento. De forma contraria, elestándar MPEG-4 proporciona la capacidad de modelar el vídeo como si estuviera compuestopor un número de objetos separados, tales como personas, coches o fondos, y cada objeto puedetener una forma arbitraria no cuadrada. El MPEG-4 utiliza los mismos bloques básicos de cons-trucción de la imagen, pero los aplica a objetos de formas arbitrarias.

Los estándares más comúnmente utilizados y sus características básicas son los siguientes:• H.261, H.263, MPEG-1, MPEG-2. Basados en la codificación de frame.

• Basados en la misma construcción fundamental de los bloques.• Predicción de la compensación de movimiento e interpolación.• Transformada 2-D DCT, Transformada del Coseno Discreta.• Conversión del espacio de color.• Cuantificación escalar, run-length, y codificación de Huffman.

• Otras herramientas incorporadas para diferentes aplicaciones.• Vídeo progresivo o entrelazado.• Compresión mejorada, flexibilización de los errores, escalabilidad,...

• MPEG-4. Codificación basada en objetos y vídeo sintético. • Se aplica a todo tipo de representación de datos. Desde video (altas y bajas tasas

de bits) y música a objetos en tres dimensiones y texto.• Permite manipular varios objetos dentro de una escena.• Permite interactuar.• Provee un sistema de entrega independiente del formato de representación y de

esa manera permite que sea usado sobre una amplia variedad de entornos para la entrega de los datos.

Seguidamente se muestran brevemente las características más sobresalientes de los diferentesestándares de compresión de vídeo. En primer lugar se examinan los estándares MPEG-1 y



MPEG-2 ya que son los más populares, posteriormente los H.261 y H.263 y finalmente se ana-liza el estándar MPEG-4 que es el más novedoso y en muchos aspectos el más revolucionario.

• MPEG-1 y MPEG-2

El grupo MPEG, Moving Pictures Expert Group, fue establecido originalmente por la ISO con elfin de desarrollar un estándar para la compresión de imágenes en movimiento, video, y audioasociado a medios de almacenamiento digital, tales como el CD-ROM. El estándar resultante,conocido comúnmente como MPEG-1, fue completamente definido en 1991 y proporciona cali-dad de vídeo VHS aproximadamente, y audio de 1.5 Mbites por segundo.

Una segunda fase de su trabajo, conocida como MPEG-2, fue planeada inicialmente como unaextensión de MPEG-1, y fue desarrollada para aplicaciones que van desde el vídeo entrelazadohasta la televisión convencional. Las velocidades de bits para las que fue desarrollado son supe-riores a los 10 Mb por segundo.

La tercera fase fue prevista para aplicaciones con más altas velocidades de bits, tal como la tele-visión digital de alta definición, HDTV, pero se comprendió que estas aplicaciones tambiénpodrían realizarse en el contexto del estándar MPEG-2. Por tanto, la tercera fase fue incorporadaen el estándar MPEG-2 y, como resultado, no existe el estándar MPEG-3.

Tanto el MPEG-1 como el MPEG-2 están formados actualmente por diferentes partes que inclu-yen vídeo, audio, sistemas, tests de conformidad, etc. La compresión de la parte de video de estosestándares se conocen frecuentemente como MPEG-1 vídeo y MPEG-2 vídeo, o MPEG-1 yMPEG-2 por brevedad.

En la actualidad el MPEG-2 vídeo ha sido adoptado como estándar para los contenidos de vídeode la televisión digital y la HDTV en la mayoría de Norte América, Europa y Asia. También es labase para el estándar de los discos de vídeo digital, DVD (Digital Versatile Video Disk).

El MPEG-2 es una versión avanzada del MPEG-1, capaz de soportar velocidades de bit másaltas, mayor resolución e imágenes entrelazadas para televisión. Para vídeo entrelazado los cam-pos pares e impares pueden codificarse separadamente o pueden combinarse un par de campospares e impares y codificarse como un frame. Para la codificación basada en campos, MPEG-2ofrece métodos basados en campos para la predicción de compensación de movimiento, DCT debloques y escaneado alternado en zigzag. Además MPEG-2 ofrece un gran número de mejorasincluyendo extensiones escalables.

En resumen, las características básicas de estos estándares son las siguientes:• MPEG-1 (1991)

• Objetivo: la compresión para medios de almacenamiento digitales, CD-ROM. • Obtiene calidad de vídeo aproximadamente VHS y audio a 1.5 Mbits/seg..

• MPEG-2 (1993) • Superconjunto de MPEG-1 para soportar velocidades de bit más altas, mayor reso-

lución e imágenes entrelazadas para televisión.



• Objetivo original: soportar vídeo entrelazado para televisión convencional. Even-tualmente se extendió para soportar HDTV.

• Ofrece codificación basada en campos y herramientas de escalabilidad.

Seguidamente se describe la estructura básica utilizada en los estándares MPEG. Los estándaresMPEG agrupan los frames de vídeo en unidades de codificación denominadas grupos de imáge-nes, o GOPs. Los GOPs tienen la propiedad de que reinicializan la predicción temporal utilizadadurante la codificación, que es importante para habilitar el acceso aleatorio en una secuencia devídeo codificada. En concreto, el primer frame de un GOP es un I-frame y los otros frames pue-den ser I, P o B frames.

En la figura 10.13 se muestra un ejemplo con un GOP de nueve frames de vídeo, formado por losframes desde I0 a B8, en los que el subíndice indica el número de frame. El frame I9 será el pri-mero del siguiente GOP. Las flechas indican las dependencias de la predicción. El frame en elprincipio de cada flecha se utiliza para predecir el frame señalado por la flecha, el frame predi-cho.

Figura 10.13 GOP con nueve frames de vídeo.

Los frames I se codifican independientemente de los otros frames. Los frames P dependen de lapredicción basada en los frames I o P anteriores. Los frames B dependen de una predicciónbasada en los frames I o P tanto anteriores como posteriores. Obsérvese que cada frame Bdepende de los datos de un frame futuro, lo que significa que el frame futuro debe descodificarseantes de que el frame B que se está tratando pueda decodificarse.

Debe observarse que la utilización de los frames B añade un retardo adicional, al necesitar espe-rar a la decodificación de frames futuros. Por tanto los frames B son muy adecuados para la emi-sión de contenidos o las aplicaciones con almacenamiento, pero muy a menudo no sonapropiados para las aplicaciones en tiempo real, comunicaciones bidireccionales o cualquier otraaplicación en la que la exigencia de mantener bajo el retardo sea importante.



El estándar MPEG codifica video en unidades jerárquicas denominadas secuencias de vídeo, gru-pos de imágenes,imágenes, slices (rebanadas), macrobloques y bloques DCT. La predicción de lacompensación de movimiento se realiza sobre bloques de 16×16 pixels. Un bloque de 16×16pixels se denomina macrobloque y se codifica utilizando DCTs de bloques de 8×8 pixels, típica-mente cuatro bloques de 8×8 pixels para la luminancia, dos bloques para la crominancia y posi-blemente un vector de movimiento hacia delante y/o hacia atrás.

Los macrobloques se escanean desde la izquierda hacia la derecha y de arriba hacia abajo. Unaserie de macrobloques se denomina slice y todos los slices de un frame contienen una imagen.Las imágenes contiguas forman un GOP, y todos los GOPs forman una secuencia completa. Lafigura 10.14 muestra la estructura del estándar MPEG con la jerarquía de capas en las que secodifica el vídeo.

Figura 10.14 Jerarquía de capas en las que se codifica el vídeo en el estándar MPEG.

Los estándares MPEG fueron diseñados para emplearse en un gran número de aplicacionesdiversas en las que cada aplicación necesita un número de herramientas diferentes o funcionali-dades distintas.

Los codificadores y decodificadores que soportan todas las funcionalidades serían muy comple-jos y caros. Sin embargo, una aplicación típica normalmente tiene suficientes herramientas conun pequeño subconjunto de las funcionalidades MPEG. En consecuencia, con el fin de facilitarlas implementaciones más eficientes para diferentes aplicaciones, MPEG agrupó juntos diversossubconjuntos apropiados de funcionalidades y definió un conjunto de perfiles y niveles.

Un perfil corresponde a un conjunto de funcionalidades que son útiles para un rango de aplica-ciones en particular. Dentro de un perfil, un nivel define el rango máximo o la complejidadmáxima de cualquiera de los parámetros de un perfil, tales como resolución, velocidad de frame,velocidad de bit, y tamaño de búfer. La figura 10.15 muestra una versión simplificada de lamatriz bidimensional de los perfiles y niveles en MPEG-2 junto con una tabla de características..

Capa GOP Capa de imagen

Capa de divisiónCapa de bloqueCapa de

macrobloque



Figura 10.15 Versión simplificada de la matriz bidimensional de los perfiles y niveles en MPEG-2.

Un decodificador se especifica mediante el perfil y el nivel que lo forma. En general, una especi-ficación de perfil / nivel más compleja es un superconjunto de perfiles / niveles menos comple-jos. Dos perfiles son ampliamente utilizados. El primero es el MP&ML, que se utiliza en lacompresión de televisión, en DVDs y en la definición estándar de la trelevisión digital, conocidacomo SD-DTV, (Standard Definition Digital Televisión). El segundo perfil muy utilizado es elMP&HL, que se usa en la compresión de HDTV.

Una vez analizados los estándares básicos de MPEG, seguidamente se describen los relacionadoscon la ITU-T.

• El estándar H.261

El estándar de compresión de vídeo H.261 se diseñó teniendo como objetivo las aplicaciones entiempo real y las comunicaciones bidireccionales. En estos entornos un requisito crítico es que elretardo sea pequeño, por ello se especificó que el retardo máximo permitido era de 150 milise-

PERFILES Simple Principal 4:2:2 SNR Espacial Alto

Alto 4:2:0

1920×1152 80 MB/s

4:2:0 o 4:2:2 1920×1152 100 MB/s

Alto 1440

4:2:0 1440×1152

60 MB/s

4:2:0 1440×1152

60 MB/s

4:2:0 o 4:2:2 1440×1152

80 MB/s

Principal

4:2:0 720×576 15 MB/s

Sin B

4:2:0 720×576 15 MB/s

4:2:2 720×608 50 MB/s

4:2:0 720×576 15 MB/s

4:2:0 o 4:2:2

720×576 20 MB/s

NIV

ELES

Bajo 4:2:0

352×288 4 MB/s

4:2:0

352×288 4 MB/s

PERFIL

NIVEL

High

Main

Low

High Main Low

(1)

(2)

(1) DVD & Digital TV: Perfil principal y Nivel principal: MP@ML (Main Profile at Main Level)

(2) HDTV: Perfil principal en Nivel Alto MP@HL (Main Profile at High Level)



gundos. El estándar RDSI se diseñó para funcionar sobre RDSI, a múltiplos p=1, 2,..., 30 de lavelocidad de la línea base RDSI, es decir a p×64 kb por segundo. El H.261 utiliza únicamente fra-mes I y P. No utiliza frames B con el fin de minimizar el retardo. Emplea estimación de movi-miento y predicción de la compensación de movimiento en bloques de 16×16 pixels y DCT porbloques de 8×8 pixels. La estimación de movimiento se calcula para obtener una precisión com-pleta de píxel. El rango de búsqueda es de ± 15 pixels.

Una particularidad interesante es que el estándar H.261 ofrece la opción de aplicar un filtro pasobaja dentro del lazo de realimentación de la predicción de compensación del movimiento con elfin de suavizar el frame previamente reconstruido como parte del proceso de predicción. Este fil-tro no se utiliza en los estándares MPEG-1 y MPEG-2, ni en el H.263 ya que utilizan estimacióndel movimiento con precisión de medio píxel y la interpolación espacial resultante tiene unefecto similar al del filtro. El estándar H.261 fue completado en 1990.

• El estándar H.263

El estándar de compresión de vídeo H.263 fue estandarizado en 1995. Fue diseñado centrando suobjetivo en las comunicaciones sobre líneas telefónicas analógicas convencionales. Transmitirvídeo, habla y datos de control utilizando un módem a 33.6 kb por segundo. Esto significa quetípicamente sólo se dispone de una capacidad de 20 a 24 kb por segundo para el contenido devídeo.

El codificador H.263 tiene una estructura similar al H.261. Fue diseñado para facilitar la intero-peratividad entre los codificadores de H.261 y H.263. Se introdujeron un gran número de mejo-ras sobre el H.261, entre las que destacan las siguientes:

1.- Reducción de la información requerida.

2.- Mejora de las especificaciones de la flexibilidad de los errores.

3.- Mejora en los algoritmos y en algunas de las técnicas de codificación para línea base, inclu-yendo estimación de movimiento de medio píxel.

4.- Mejoras en la eficiencia de la compresión mediante cuatro opciones de codificación avan-zada. Son las siguientes:

- Modo de vector de movimiento no restringido.

- Modo de predicción avanzada.

- Modo de codificación aritmética basada en sintaxis.

- Modo de frames PB.

Las opciones de codificación avanzadas se negocian de manera que el codificador y el decodifi-cador se comunican para determinar qué opciones pueden utilizarse antes de que comience lacompresión.



Cuando se utilizan todas las opciones de codificación el estándar H.263 ofrece mejoras significa-tivas en la calidad respecto al H.261, en particular a muy bajas velocidades de bits. Por ejemplo,a velocidades por debajo de los 64 kb por segundo el estándar H.263 obtiene típicamente unamejora de aproximadamente 4 dB respecto al estándar H.261 a la misma velocidad de bits, o unareducción del 50% en la velocidad de bits para la misma calidad en la relación señal-ruido, SNR.

• El estándar H.263+ (Versión 2)

El estándar H.263+ es una extensión del H.263, es decir, se corresponde con el H.263 con algu-nas especificaciones adicionales. Su nombre oficial es H.263, Versión 2. El H.263+ soporta unrango de formatos de vídeo más amplio, e incluye nuevas especificaciones para obtener caracte-rísticas de la compresión mejoradas, mejorar la flexibilidad a los errores para la transmisión enpaquetes sobre redes. También ofrece escalabilidad temporal. Espacial y SNR.

El estándar H.263+ fue completamente definido en 1997. En la actualidad se está finalizando laestandarización de una nueva extensión, el H.263++, oficialmente el H.263 Versión 3.

Además se está desarrollando un nuevo estándar de compresión, el H.26L, donde la L indicagrande (large). El H.26L será un estándar completamente nuevo en el sentido de que no tienerequisitos ni limitaciones de compatibilidad con los anteriores estándares H.263, y por tanto noserá compatible.

• El estándar MPEG-4

El estándar MPEG-4 es bastante diferente de sus predecesores, MPEG-1 y MPEG-2, ya que susprincipales objetivos se centran en permitir nuevas funcionalidades y no sólo en proporcionarmejoras en la compresión. El MPEG-4 soporta una representación basada en objetos o basada encontenidos. Esto facilita la codificación separada de diferentes objetos de vídeo en una escena devideo. Además permite el acceso individualizado y la manipulación de diferentes objetos en unvídeo. Obsérvese que el MPEG-4 no especifica cómo identificar o segmentar los objetos en unvídeo. Esta operación se realiza en el codificador que no está especificado en el estándar. Sinembargo, si se conocen los objetos individuales, el MPEG-4 proporciona un método para com-primir estos objetos. El acceso y la manipulación basada en contenidos es una de las característi-cas fundamentales.

El MPEG-4 también soporta la compresión de objetos de vídeo sintéticos o generados por com-putador, así como la integración de los objetos naturales y sintéticos dentro de un único vídeo.También facilita la interacción con los objetos individuales del vídeo.

Además soporta comunicaciones flexibles a los errores en canales como Internet y la tercerageneración de sistemas sin cables, gíreles, resultando por tanto más robusto. También incluye lamayoría de las técnicas de codificación desarrolladas en los anteriores estándares. Como resul-tado de ello, el MPEG-4 soporta codificación de vídeo basada tanto en frames como en objetos.La primera versión del MPEG-4 finalizó en 1999. Una segunda versión, conocida como MPEG-4 Versión 2, fue estandarizada en 2000.



La figura 10.16 muestra un ejemplo de decodificación MPEG-4 desarrollado en el comité deestandarización del MPEG-4.

Figura 10.16 Ejemplo de decodificación MPEG-4 desarrollado en el comité de estandarización del MPEG-4.

Como puede observarse el vídeo está formado por dos objetos naturales, la persona y la mesa, yun objeto sintético que es la presentación. También hay un objeto natural de audio.

Los distintos objetos se codifican independientemente. Con una descripción de la escena, se mul-tiplexa en una única secuencia de bits y se envía por la red. El decodificador recibe la secuenciade bits y demultiplexa los objetos codificados y la descripción de la escena. Los objetos codifica-dos individualmente se descodifican y la descripción de la escena representan la manera en quelos diferentes objetos se componen y renderizan para formar el vídeo final que será presentado.La figura 10.16 muestra cómo los objetos naturales y sintéticos pueden integrarse en la mismaescena.

Además, la representación basada en objetos facilita la manipulación o la interacción con losobjetos individuales en la escena. Por ejemplo, un objeto puede borrarse de la escena y otropuede ser añadido.

• Comparación de los estándares MPEG-1/2 y H.261/3 con el MPEG-4

Existen varias diferencias importantes que resultan evidentes cuando se comparan los estándaresde compresión. MPEG-1, MPEG-2, H.261, y H.263 fueron diseñados originariamente para com-primir vídeo. Ofrecen métodos para el almacenamiento o la transmisión de vídeo, utilizan méto-dos de codificación basados en frames y están principalmente diseñados para lasimplementaciones hardware.



Por el contrario, el estándar MPEG-4 se diseñó como una gran conjunto de herramientas para unagran variedad de aplicaciones. Estas herramientas soportan tanto codificación basada en objetoscomo basada en frames, y también soporta la codificación de vídeo sintético.

El MPEG-4 pone el énfasis en el desarrollo de software y ofrece la capacidad de descargar cier-tos tipos de algoritmos que pueden utilizarse en el decodificador para soportar una gran variedadde aplicaciones, tales como interactuar con el vídeo o manejar recursos del decodificador cliente.Debe tenerse en cuenta que el MPEG-4 permite la descarga de algoritmos pero no de codificado-res y descodificadores.

• Otros estándares MPEG

MPEG desarrolla dos estándares que se extienden más allá de la visión tradicional de la compre-sión de vídeo y audio. Aunque estos estándares no se centran en la compresión, se mencionanbrevemente con el fin de clarificar su relación con los otros estándar MPEG..

El objetivo del MPEG-7 es facilitar la búsqueda rápida y eficiente de contenidos multimedia, demanera similar al modo en que lo realizan las herramientas o aplicaciones de búsqueda conven-cionales en Internet, que facilitan las búsquedas rápidas de información textual.

En concreto el estándar de la descripción del interfaz de los contenidos multimedia define unconjunto de descriptores que pueden utilizarse para describir varios tipos de información multi-media, tales como imágenes, vídeo, gráficos, habla u audio, así como información sobre la crea-ción y composición de estos elementos.

Mientras que los anteriores estándares MPEG definieron nuevos estándares de compresión, elobjetivo del MPEG-7 es representar la información describiendo el contenido y no el contenidoen sí mismo.

El MPEG-21 es una nueva estandarización. Su objetivo es facilitar el comercio electrónico de loscontenidos digitales. Se pretende que tenga una interoperatividad completa y transparente paralos contenidos que se manejen, disponiendo de forma conjunta la infraestructura de reparto, defacturación y de derechos. Es bastante diferente de los estándares MPEG basados en la compre-sión. Sin embargo, incorporará los estándares de compresión, en particular el MPEG-2 y elMPEG-4, para la compresión el suministro de contenidos.

• Otros estándares: Propietarios

Como es de suponer los métodos de compresión de propietario se caracterizan por pertenecer auna empresa o un conjunto de ellas y suelen desarrollarse con objetivos particulares. Un ejemplode ellos son los métodos para las Palm, que disponen de utilidades incompatibles entre productosde distintos fabricantes. los usuarios de PocketPC lo tenían más fácil y cómodo: puesto queMicrosoft siempre ha mantenido que los PPC son realmente multimedia, por lo que el Media Pla-yer venia de serie. Eso permitía ver algunos AVI.

• DivX. Un codec de especial interés.



DivX, Digital Video Express, es un formato inicialmente pensado para aplicaciones DVD-ROMpromocionado por varias grandes compañías de Hollywood, entre las que destacan Disney, Drea-mworks SKG, Paramount y Universal.

Originalmente se diseñó como sistema de protección a copias de DVDs y vídeo bajo demanda,aunque no tuvo éxito. Hoy en día es un compresor de vídeo basado en MPEG-4, con lo queobtiene una mejor compresión respecto al MPEG-2 que se utiliza en los DVDs, en concreto alre-dedor de un 10%, es decir, el tamaño de la secuencia es un 10% menor. La compresión con res-pecto a una cinta VHS está alrededor en un factor de 100. Además utiliza MP3 para lacompresión de audio.

Las primeras compañías que lanzaron reproductores DVD capaces de soportar el formato DivXfueron Kiss Technology en Europa y Liteon en USA. Lo hicieron utilizando chips Sigma DesignsEM8500 chipsets. La empresa Sigma Designs destacó al ser la primera que fabricó tarjetas PCIpara la compresión y descompresión mediante hardware. En diciembre de 2003 MediaTek lanzóla serie de chips MT1389 que estaban completamente garantizados por DivXNetworks (laempresa oficial de DivX). Inmediatamente, en enero, ESS lanzólos chips Vibratto, que tambiénsoportaban DivX. A partir de entonces se ha producido una explosión de reproductores DivX enel mercado, con los chips MediaTek en la mayoría de los productos europeos.

En la actualidad, diversos fabricantes de reproductores de DVD han puesto en el mercado repro-ductores que soportan DivX, tales como LiteOn, Kiss, Revoy y Philips

DivX es un códec AVI (Audio vides Interleaved, los AVI se analizan detalladamente a continua-ción) que puede usarse tanto en capturas en tiempo real como en compresión en tiempo no realgracias a la opción de comprimir a doble pasada incorporada en la versión 4. La versión 5 estádisponible en tres versiones. La estándar incluye, principalmente opciones para reproducir vídeocomprimido con DivX.

DivX no dispone de ninguna utilidad de compresión independiente o "stand alone", sino que seinstala como un codec AVI o Direct X disponible en el sistema. Es decir, solamente se puedecomprimir vídeo usando el codec DivX desde una aplicación que trabaje vídeo AVI, como pue-den ser Adobe Premiere, Ulead Media Studio, Xmpeg o Virtual Dub.

Aunque los vídeos resultantes son ".avi" en realidad DivX está basado en el códec MPEG-4. Estecódec fue diseñado para la transmisión de vídeo mediante Internet, por lo que su código estáespecialmente optimizado para vídeos de muy baja velocidad de bit. Por tanto es ideal pararecomprimir una película de 2 horas y almacenarla en un sólo CD. Otra característica importantede DivX es que, al contrario que muchos otros codecs de compresión, admite entrada de vídeo enformato YUV2, lo que acelera notablemente el proceso de compresión.



10.6 FORMATOS DE ARCHIVO DE VÍDEO.

El almacenamiento de contenidos de vídeo se realiza, como todos, en archivos, pero no es tareafácil. Como es lógico el vídeo no suele estar compuesto únicamente de una secuencia de imáge-nes, sino que suele estar formado por vídeo, sonido e incluso subtítulos.

Además, toda esa información debe ir sincronizada ya que en otro caso se sufrirá el efecto cono-cido como error de "lipsync", es decir, el movimiento de los labios no se corresponde con elaudio que se escucha.

Si se produce desincronización, ésta puede ser de tres tipos:• El audio está desplazado en el tiempo con respecto al vídeo• El audio tiene distinto tiempo de duración que el vídeo• El audio está desplazado en el tiempo y tienen distinta duración que el vídeo

La última es una combinación de las dos primeras, y la corrección de la desincronización va a sermás complicada, pudiendo llegar a ser imposible.

• Desincronización constante (desplazamiento en el tiempo)

En este caso, tiene que adelantarse o retrasarse el audio, un tiempo equivalente al que se corres-ponde con la desincronización que tengamos. Este es un proceso iterativo, es decir, reprodu-ciendo la película se calcula cuál es el valor de la desincronización existente, se realiza lacorrección y se verifica si se ha corregido la desincronización, en caso contrario, se vuelve aempezar el proceso.

Para obtener una idea del valor de la desincronización existente, puede tomarse un pasaje de lapelícula en dónde sea fácil realizar esto, por ejemplo en el disparo de un arma, el ruido de unapuerta al cerrarse o algo por el estilo, nunca deberemos fiarnos de las voces, ya que como estándobladas muchas veces el movimiento de los labios no coincide con el sonido.

Desincronización progresiva (distinto tiempo de duración)

Si el vídeo y el audio tienen duración distinta, cuando se reproduce la película, a medida que vaavanzando ésta, se va notando una desincronización progresiva, de forma que al final de la pelí-cula, la desincronización es máxima.

• Desincronización con desplazamiento en el tiempo y distinta duración.

Como ya se comentó anteriormente, este caso es una combinación de los dos anteriores, y es lopeor que podría pasar. La solución pasa por una mezcla de las dos anteriores, pero ambos efectoshacen que sea sumamente complicada.

En general, las soluciones que funcionan bien para el audio no lo hacen para el video y a lainversa. Por ello desde el principio se tuvo bastante claro que lo mejor era manejar cada cosa porseparado. Pero lógicamente, desde el punto de vista de los usuarios, es deseable tener un únicofichero.



Este problema se ha resuelto con los formatos de distribución. Se diseñó un formato de ficheroque actuase de contenedor de varios canales de información. Además a esos formatos se les dotóde toda la información necesaria para sincronizar los diferentes canales. Esos formatos son losque habitualmente conocemos como "formatos de video" entre los que se encuentran AVI, MOV(Quicktime) y WMF (Windows Media file). Con ello, saber que una película es un AVI, lo únicoque indica es cómo está organizada la información dentro del fichero, no cómo es esa informa-ción.

Por ejemplo si queremos guardar video de 320x160 pixeles a 24 frames por segundo con 16 bitsde color se necesitan 320x160x16x24 = 19660800 bits por segundo = 18.75 Mbits por segundo,que es una cantidad muy importante de información, pues implica 140 Mbytes por minuto. Esdecir en un CD se podrían almacenar 4.55 minutos de video (y obsérvese que la resolución esmuy baja). Evidentemente es necesario comprimir la información. Con lo que el segundo paso aconsiderar es el método de compresión de video que se ha utilizado. Dependiendo de cuál sehaya utilizado, se dice por ejemplo que un AVI es DivX o Cinepak. Realmente lo que se deberíadecir es que este AVI contiene un canal de video codificado mediante DivX o Cinepak. En elmundo Apple, el formato es el MOV, también llamado QuickTime, y el codec habitual es elQuickTime, que realmente es una implementación de MPEG4, igual que el DivX. No deben con-fundirse el continente y el contenido pese a que por economía de lenguaje aparentemente sean lomismo.

Lo mismo ocurre con el audio. También se comprime para reducir su tamaño y se hace con uncodec diferente al video y específico para el audio. Por eso, dentro de un AVI se puede tenervideo DivX y el audio codificado como un MP3 o como un OGG, PCM o WMA

Es inmediato comprender que los formatos de fichero están íntimamente relacionados con losmétodos de compresión, ya que la información que tendrán que contener los archivos dependeráde cómo sea la compresión. Por ello es lógico que para cada estándar de compresión se determineun tipo de archivo.

Seguidamente se describen los más destacados y sus características fundamentales.

10.6.1 AVI: AUDIO VIDEO INTERLEAVED Audio video Intercalado. Fue definido por Microsoft en 1992 y es uno de los más comúnmenteutilizado en la actualidad. Es un formato de fichero de video que permite la reproducción delvídeo mediante herramientas únicamente software, y es el estándar para la arquitectura multime-dia VFW (Video For Windows).

Las cámaras de vídeo digitales más comunes crean AVI cuando se importan las secuencias DVdesde la cámara. Estos archivos se suelen denominar DV-AVI porque la información de vídeoincluida en el fichero es DV o miniDV.

En este formato los datos de audio y video se entrelazan de manera que a un segmento de vídeole sigue uno de audio, por lo que produce una reproducción suave. Puede manejar 16.7 millones



de colores, y aproximadamente 10 Megabytes de video por minuto. Soporta diferentes métodosde compresión.

El formato AVI es una caso especial de archivo RIFF (Resource Interchange File Format). Estaes una especificación diseñada en 1991 para almacenar contenidos multimedia. Pueden almace-narse datos desde objetos de C++ hasta vídeos completos, y pueden añadirse nuevos tipos dedatos.

Las aplicaciones pueden ignorar los tipos de datos que no puedan procesar de un fichero RIFF,con lo que se previene que el software quede obsoleto por el hecho de que se introduzca unnuevo tipo de datos.

La mayor limitación de este formato es que en principio la zona de datos no puede exceder loscuatro gigabytes, debido a que está definido para 32 bits.

Figura 10.17 Esquema del Chunk del archivo RIFF

La base de la especificación RIFF es una estructura de datos conocida como chunk, sección, quecontiene un único identificador de chunk.

La estructura general es la siguiente:

1.- Cabecera (RIFF Form Header)RIFF' (4 byte file size) 'xxxx'donde 'xxxx' identifica la especialización, o forma, del RIFF. 'AVI ', por ejemplo.

2.- Una sección (Chunk)(4 byte de identificador) (4 byte de tamaño de sección) (datos)

3.- Una Lista'LIST' (4 byte de tamaño de la lista) (4 byte de identificadores de la lista) (datos)donde los datos incluyen listas o secciones.



La figura 10.17 muestra el esquema general del Chunk del archivo RIFF. Se mantiene la termino-logía en inglés porque serán los nombres de los campos en el estándar.

El formato AVI es una especialización o "forma" del RIFF. La figura 10.18 muestra la estructurabásica de este formato de archivo.

Figura 10.18 Estructura básica del formato de archivo AVI.

Cada lista 'rec ' contiene los datos de sonido y vídeo para un único frame en el segmento de datosde sonido y en el de vídeo.

Los datos de sonido son normalmente PCM de 8 o 16 bits, estéreo o mono, muestreado a 11, 22,o 44.1 KHz.

Los datos de vídeo en un archivo AVI puede estar comprimidos de diversas formas. Por ejemplo,en las aplicaciones de Video para Windows pueden utilizarse los compresores Intel Indeo (ver-sion 3.2), Microsoft Video 1, Microsoft RLE (Run Length Encoding), CinePak, DivX,...

Los ficheros AVI contienen un código de cuatro caracteres, como 'IV31' o 'CVID', en la cabecerade la secuencia, que identifica el compresor utilizado. Por ejemplo, 'CVID' es el identificadorpara CinePak, un compresor pionero para video compacto. Para el Indeo Video Interactive (Indeo4.1, basada en la compresión mediante algoritmos wavelet) es 'iv41', etc.

Por último, y con el único fin de presentar el tipo de información que se detalla en el archivo,seguidamente se detallan los contenidos de las cabeceras básicas.

En chunk de encabezado AVI, contiene la siguiente información:

Total Frames: Número total de Frames (por ejemplo, 1500 frames en un AVI)

Streams: secciones (por ejemplo, 2 para audio y vídeo juntos)

'RIFF' (4 byte file length) 'AVI ' // file header 'LIST' (4 byte list length) 'hdrl' // list of headers for AVI file 'avih' (4 byte chunk size) (data) // AVI header 'LIST' (4 byte list length) 'strl' // stream list 'strh' (4 byte chunk size) (data) // video stream header 'strf' (4 byte chunk size) (data) // video stream format 'LIST' (4 byte list length) 'strl' // stream list 'strh' (4 byte chunk size) (data) // audio stream header 'strf' (4 byte chunk size) (data) // audio stream format (optional junk chunk to align on 2K byte boundary) 'LIST' (4 byte list length) 'movi' // list of movie data one or more ... 'LIST' (4 byte list length) 'rec ' '##wb' (4 byte chunk size) (data) // sound data '##dc' (4 byte chunk size) (data) // video data optional index 'idx1' (4 byte chunk size) (index data) // index into movie



InitialFrames: Frames iniciales

MaxBytes: Número máximo de bytes

BufferSize: Tamaño del búfer.

Microseconds per Frame: microsegundos por frame

Frames per second: frames por segundo (por ejemplo, 15 fps)

Size: tamaño (por ejemplo, 320x240 pixels)

Flags: Indicadores.

El chunk o encabezado de secuencia o sección contiene la siguiente información:

Stream Type: tipo de stream (por ejemplo, 'vids' para vídeo y 'auds' para audio).

Stream Handler: controlador (por ejemplo, 'cvid' para CinePak)

Samples Per Second: muestras por segundo (por ejemplo, 15 frames/segundo para vídeo)

Priority: indica la prioridad

InitialFrames: Frames iniciales

Start: principio

Length: longitud en número de frames (por ejemplo, 1500 frames para vídeo)

Length (sec): longitud en segundos (por ejemplo, 100 segundos para vídeo)

Flags: Indicadores

BufferSize: Tamaño del búfer.

Quality: calidad

SampleSize: Tamaño de la muestra o frame.

Para vídeo, el chunk Formato del Stream contiene la siguiente información:

Size: Tamaño (por ejemplo, 320x240 pixels)

Bit Depth: profundidad de bit (por ejemplo, 24 bits de color)

Colors Used: colores usados (por ejemplo, 236 para la paleta de color)

Compression: tipo de compresión utilizada (por ejemplo, 'cvid' para CinePak)

Para audio, el chunk Formato del Stream contiene la siguiente información:

wFormatTag: indica tipo de formato de audio (por ejemplo, WAVE_FORMAT_PCM)

Number of Channels: número de canales (por ejemplo, 2 para sonido estéreo)

Samples per Second: muestras por segundo (por ejemplo 11025 muestras por segundo)



Average Bytes Per Second: Número medio de bytes por segundo (por ejemplo, 11025 parasonido de 8 bits.

NblockAlign: número de alineamiento de bloque

Bits Per Sample: número de bits utilizados para cada muestra (por ejemplo 8 ó 16 bits)

También se pueden encontrar otros chunks que no forman parte del estándar, como puede ser elsiguiente:

'LIST' (4 bytes para tamaño de la lista) 'INFO'

Permite almacenar información para ayudar a identificar el contenido de un chunk.

Los datos de audio son típicamente PCM de 8 ó 16 bits, stereo o mono, muestreados a 11, 22 ó44.1 kHz. Tradicionalmente se ha venido utilizando para la digitalización del sonido el WindowsPCM. Sin embargo, debido a su importante uso en Internet y las limitaciones de ancho de bandaexistentes en la red, se ha incrementado el uso de codificadores de audio. Es por ello que elcampo wFormatTag en el chunk de audio identifica el formato de audio y el codificador.

10.6.2 MPEG: MOTION PICTURE EXPERT GROUPFue desarrollado por el grupo MPEG de la International Standards Organization (ISO). El for-mato de archivo almacena secuencias de datos en los medios de almacenamiento digitales. Seutiliza tanto para audio como para vídeo, texto, y gráficos, mediante una única secuencia de datossincronizada.

Las extensiones de los archivos con este formato son .mpeg, .MP1, .MP2, MP3 y MP4. La tecno-logía que utiliza incluye patentes muy diversas de compañías e individuos de diferentes partesdel mundo ya que el comité MPEG sólo estableces el estándar técnico. El grupo de derechos depropiedad intelectual MPEG-IPR (intellectual property rights) se constituyó oficialmente enParis en marzo de 1994 con más de 50 compañías entre fabricantes y usuarios de la tecnología decompresión digital.

Este formato de archivo puede encontrarse en todas las plataformas en sus diversas versiones,MPEG-1 (Standard), MPEG-2, MPEG-3, MPEG-4.

Soporta colores por encima de los 24 bits (4:2:0 del espacio de color YCbCr), el tipo de imagenes bitmap y soporta imágenes múltiples. La tecnología de compresión se basa en los estándaresMPEG.

La resolución de la secuencia de vídeo fue en principio relativamente baja, posiblemente diezveces menos que la original, pero tenía una alta calidad de audio para CD.

En realidad no se ha definido concretamente un formato de archivo genérico para todos losMPEG. Todo lo que se requiere para reproducir los datos MPEG es incluido directamente en lasecuencia de datos. Por tanto no son necesarias cabeceras ni cualquier otro tipo de campo de



información. Sin embargo, es posible que algún organismo internacional como MPEG o el DSM(Digital Storage Medium), subgrupo de MPEG, lo haga en algún momento.

Normalmente los formatos de archivo se describen en términos de offsets, (desplazamientos),pero esto no es posible en MPEG porque resulta muy complicado por diversas razones. En pri-mer lugar los campos de información se cuentan en bits en lugar de bytes, en segundo lugardebido a la existencia de muchos campos de información que depende de valores de camposanteriores y por último a que la mayoría de la información se propociona con códigos de longitudvariable. Por ejemplo, los coeficientes de la transformada DCT se codifican de acuerdo con latabla mostrada en la figura 10.2. En ella, el nivel indica el valor de la DCT y la secuencia deceros define cuántos son ceros antes de él. La tabla completa tiene 112 entradas. De esta manera,el estándar MPEG ISO 11172 describe el formato de archivo mediante un lenguaje tipo C.

Tabla 10.2 Tabla de codificación de los coeficientes de la transformada DCT.

Otro aspecto fundamental es que los coeficientes de la transformada DC se codifican como dife-rencias respecto a los coeficientes del bloque anterior porque se supone que en promedio el brilloes similar en bloques cercanos. Debido a la codificación con longitud de palabra variable, lasdiferencias pequeñas se codifican con menos bits que las grandes.

En el pasado la mayoría de los archivos MPEG respondían al estándar ISO/IEC 11172-2.perofueron apareciendo cada vez más ficheros del estándar ISO/IEC 111hardware72-1, porque lamayoría del hardware producía ficheros de los layer I/II MPEG con contenidos de vídeo y audio.La estructura de fichero se muestra en la figura 10.19.

código (en bits) run level 11 0 1 011 1 1 0100 0 2 0101 2 1 00101 0 3 00111 3 1 00110 4 1 000110 1 2 000111 5 1 000101 6 1

................. 0000000000011111 27 1 0000000000011110 28 1 0000000000011101 29 1 0000000000011100 30 1 0000000000011011 31 1



Figura 10.19 Estructura del fichero

El fichero está compuesto por grupos (packs) que contienen paquetes (packets). Los paquetes sonde vídeo o de audio. Una cadena del Layer I MPEG puede tener hasta 16 canales de vídeo y 32 deaudio. Si se concatenan el paquete de datos de un canal de vídeo byte a byte se obtendría unarchivo de vídeo MPEG que respondería al estándar ISO/IEC 11172-2.

A continuación se describe la estructura básica de los archivos MPEG.

Los codificadores de audio y video proporcionan a su salida los trenes elementales de datos (Ele-mentary Streams, ES) que constituyen la capa de compresión (compresión layer).

Cada tren elemental se compone de unidades de acceso (Access Units, AU), que son las repre-sentaciones codificadas de las unidades de presentación (Presentation Units, PU), es decir, lasimágenes o tramas de sonido decodificadas dependiendo si se trata de video o audio respectiva-mente.

Estos trenes de datos, así como otros datos llamados "privados" (private data), se combinan deforma ordenada y ampliados con información diversa que permite al decodificador separarlos ygarantizar la sincronización de la imagen y el sonido en la reproducción.

• Estructura MPEG 1

En MPEG 1 la parte 1 de la norma ISO/IEC 11172 (MPEG-1), denominada sistema, define lasreglas para la constitución de una "capa de sistema" (system layer) que agrupa el video, el audioy los datos privados en un solo tren, así como las condiciones sobre los trenes elementales quepermitan asegurar esta combinación.

Las cinco funciones básicas de la capa de sistema que empaqueta la capa de compresión son lassiguientes:

• Sincronización de los múltiples trenes elementales comprimidos en la reproducción.• Combinación de estos trenes múltiples en un solo tren de datos.• Inicialización de las memorias intermedias (bufers) al comienzo de la reproducción.• Gestión continua de estas memorias intermedias.• Por ultimo, identificación del tiempo por marcadores (time stamps).

Un conjunto de codificación MPEG-1 de sistema debe realizar la codificación de los datos devideo y audio, después el multiplexado de esta información y de los datos privados, añadiendo la

Código de comienzo de pack Cabecera de pack packet (paquete) packet (paquete) packet (paquete) código de fin

Código de comienzo de packet Cabecera de packet datos del packet



información necesaria para su sincronización y otras relativas a los recursos necesarios para ladecodificación del tren binario MPEG-1, tales como el tamaño de las memorias intermediasnecesarias para la decodificación de cada uno de los trenes elementales con un decodificador defrecuencia llamado System Target Decoder, (STD).

Cada tren elemental se divide en paquetes que constituyen así un Packetized Elementary Stream(PES). Un paquete está constituido por una cabecera de paquete (packet header) seguido de losdatos. La figura 10.20 muestra la estructura de un PES..

Figura 10.20 Estructura de un paquete PES

La cabecera del paquete empieza por un código de inicio de 32 bits, donde los 8 últimos bitsidentifican el tipo (audio, video o datos privados) y el número del tren elemental al que elpaquete de datos pertenece. La cabecera indica la longitud del paquete y el tamaño de la memoriaintermedia de entrada necesaria para su decodificación por el STD. La tabla 10.3 muestra lainformación en un PES.

Tabla 10.3 Información en un PES.

También puede contener un marcador de decodificación (Decoding Time Stamp, DTS) que indi-que el momento de decodificación de la primera unidad de acceso (AU) del paquete y/o un mar-cador de presentación (Presentation Time Stamp, PTS) que indique el instante donde la unidad depresentación correspondiente (PU) debe ser "presentada" (visualizada o sonorizada, según pro-ceda).

Código de comienzo Stream ID PTS STD DATOS ...

Paquete PES

Cabecera de Paquete

Campo Definición (comentario) N.de bits start_code_prefix prefijo del código de inicio (00 00 01 hex) 24 stream_id tipo (4 bits de mayor peso) y núm. (4 bits de menor peso) del PES 8 packet_length longitud del PES (número de bytes restantes que siguen) 16 stuffing_bytes bytes de relleno opcionales (valor FF hex) 0 a 16x8 bits "01" principio del campo STD_buffer 2 STD_buffer_scale factor de escala para el buffer (0=128 bytes, 1=1024 bytes) 1 STD_buffer_size tamaño del buffer (en múltiplos de 128 o 1024 bytes) 13 PTS (opcional) marcador de presentación (código de 4 bits+33 bits+marcador de 3

bits) 40

DTS (opcional) marcador de decodificación (misma estructura que PTS) 40 packet_data_byte datos (N=packet_length menos tamaño de los 6 campos sig.) Nx8



Cuando por ejemplo una secuencia de video debe ser presentada en un orden de IBBP, estas sontransmitidas con anterioridad en un orden de IPBB. Por tanto deben usarse dos tipos de marcasde tiempo. El decodificador de marca de tiempo DTS indica el tiempo cuando una imagen debeser codificada, mientras la presentación de marcas de tiempo PTS indica cuando esta debe serpresentada a la salida del decodificador.

Cuando una secuencia IPBB es recibida, las dos imágenes I y P deben ser decodificadas antes dela primera imagen B. Como un decodificador sólo puede decodificar una imagen al mismotiempo; se debe decodificar una imagen I primero y luego debe ser almacenada, para tambiéndecodificar después una imagen P, con las cuales se pueden crear las imágenes B esperadas.

La figura 10.21 ilustra este procedimiento Primero se recibe una imagen I con sus respectivasmarcas de tiempo DST y PTS, estas marcas de tiempo son separadas un periodo de imagen. Si lacodificación es bidireccional, una imagen P debe seguir y esta también vendrá con marcas detiempo DTS y PTS, pero la separación entre las dos marcas de tiempo es de tres periodos de ima-gen, para permitir la inclusión de la imagen B. De este modo una secuencia IPBB es recibida. I esdemorada un periodo de imagen, P es demorada tres periodos de imagen, las dos imágenes B noson demoradas y la presentación de la secuencia descodificada es IBBP. Claramente si la estruc-tura de las GOPs es cambiada de tal forma que hayan mas imágenes B entre I y P las diferenciasentre DTS y PTS de las imágenes P será muy grande.

En los paquetes de audio existen marcas de tiempo del tipo PTS, pero como los paquetes de audionunca son transmitidos fuera de secuencia, entonces no hay marcas de tiempo del tipo DTS.

Figura 10.21 Ejemplo de cómo se usan PTS/DTS para sincronizar una codificación bidireccional

Como se transmitió I P1 B1 B2 P2 B3

PTS N+1 N+4 N+2 N+3 N+7 N+5 … DTS N N+1 - - N+4 - …

Como se decodificó N N+1 N+2 N+3 N+4 N+5 I P1 B1 B2 P2 B3 …

I B1 B2 P1 B3 … N+1 N+2 N+3 N+4 N+5

Como se debe mostrar



Estos marcadores sirven también para sincronizar las funciones de decodificación de audio yvideo, enviándose con relativa frecuencia (la norma especifica un intervalo máximo de 0.7segundos).

Se codifican sobre 33 bits, que representan un tiempo absoluto expresado en ciclos de reloj dereferencia a 90 KHz.

Un paquete puede contener a continuación un número variable de bytes de datos, en función delas características del soporte de grabación o de transmisión utilizado.

La norma prevé también la posibilidad de añadir un tren elemental de ajuste (padding stream)para obtener un flujo constante o alinearse sobre los sectores físicos de un dispositivo de almace-namiento, así como los bytes de relleno (stuffing bytes) en el interior de un paquete (máximo 16por paquete).

Los paquetes se agrupan en packs, cuya cabecera (pack header) proporciona la información detiming y de flujo mediante los campos de referencia de reloj de sistema (System Clock Refe-rence, SCR).

Los campos SCR se utilizan para sincronizar en el decodificador un reloj de sistema común a 90KHz (System Time Clock, STC) que sirve de base de tiempos y de unidad de medida para loscampos DTS y PTS de los paquetes. La figura 10.22 muestra la formación de un paquete comoconjunto de PES..

Figura 10.22 Paquete: conjunto de paquetes PES

La cabecera del paquete, que se muestra en la tabla 10.4, comienza con un código de inicio de 32bits.

El primer paquete de un tren MPEG-1 contiene obligatoriamente una cabecera de sistema (sys-tem header).

Se trata de un paquete especial que resume el conjunto de parámetros del sistema utilizados parael transcurso de este tren (flujo máximo, identificación de los trenes elementales de audio, videoy datos, tamaño mínimo del buffer de entrada, etc.).

La cabecera de sistema opcionalmente puede ser respetada durante cualquier nuevo paquete encurso del tren MPEG-1 para facilitar el acceso a un punto cualquiera de este tren. Esta cabecera

Paquete de encabezamientos que contiene SCR

Paquete PES

Video Audio Video Audio...........

Paquete

Encabezamientos PES (PTS/DTS)



de sistema empieza también por un código de inicio de 32 bits. La tabla 10.5 muestra la estruc-tura.

Tabla 10.4 Estructura de la cabecera de un paquete MPEG-1

Figura 10.23 Contenido de un paquete MPEG-1

Campo Definición (comentario) N. de bits pack_start_code código de inicio del paquete (00 00 01 BA hex) 32 bits "0010" principio del campo SCR 4 SCR [32...30] reloj de referencia del sistema (3 bits de mayor peso) 3 marker_bit bit siempre a "1" 1 SCR [29...15] reloj de referencia del sistema (15 bits de peso medio) 15 marker_bit bit siempre a "1" 1 SCR [14...0] reloj de referencia del sistema (15 bits de menor peso) 15 marker_bit bit siempre a "1" 1 marker_bit bit siempre a "1" 1 mux_rate velocidad del multiplex MPEG (en múltiplos de 50 bytes/s) 22 marker_bit bit siempre a "1" 1

Cabecera dePaquete

(Pack header)

Paquete deCabecera del

sistema

(System header)

Paquete deCabecera del

sistema

(System header)

... SiguientesPaquetes ...

(número variable)

ÚltimoPaquete

Código deFinal

(ISO 11172)

Paquete Número 1

Contenido:Pack_Start_Code (32 bits)System_Clock_ReferenceMux_Rate

Contenido:Información del sistema,número y tipo de los treneselementales, PID de los PES

Contenido:PES de Audio,PES de Vídeodatos privados

Paquete Número 1



Tabla 10.5 Estructura de la cabecera del sistema MPEG-1

El número de trenes elementales que pueden componer un tren MPEG-1 se especifica delsiguiente modo:

• video: 0 a 16 • audio: 0 a 32 • datos privados: 0 a 2

Campo Definición (comentario) N.de bits

system_header_start_code código de inicio de cabecera de sistema 32

header_length longitud de cabecera (N. de bytes que quedan por seguir) 16

marker_bit bit siempre a "1" 1

rate_bound velocidad máxima (mux_rate) de la secuencia 22


audio_bound N. de PES de audio del bitstream (0 a 32) 6

fixed_flag indica velocidad fija ("1") o variable ("0") 1

CSPS_flag "1" si bitstream utiliza el "constrained parameter set" 1

system_audio_lock_flag "1" indica relación armónica entre STC y Fmuestreo de audio 1

system_video_lock_flag "1" indica relación armónica entre STC y F.imagen 1


video_bound N. de PES de video del bitstream (0 a 16) 5

reserved_byte reservado para futuras ampliaciones 8

stream_ID1 identificación del primer PES (naturaleza y número) 8

bits "11" bit de comienzo del campo STD_buffer 2

STD_buffer_bound_scale1 "0" =128 bytes (audio), "1"=1024 bytes (video) 1

STD_buffer_size_bound1 tamaño máx. del buffer (múltiplo de 128 o 1024 bytes) 13

stream_ID2 identificación del segundo PES (naturaleza y número) 8

bits "11" bit de comienzo del campo STD_buffer 2

STD_buffer_bound_scale2 "0" =128 bytes (audio), "1"=1024 bytes (video) 1

STD_buffer_size_bound2 tamaño máx. del buffer (múltiplo de 128 o 1024 bytes) 13

etc. para (n-2) otros PES idem para todos los PES (máx. 16 video, 32 audio, 2 private) (n-2)x24



El tren MPEG-1 termina con un código final, también de 32 bits (00 00 01 B9 hex).

La figura 10.23 muestra de forma esquemática el contenido de un tren MPEG-1 completo.• Estructura MPEG 2

Al igual que en MPEG-1, los trenes elementales (ES) están organizados en paquetes para formarlos Packetized Elementary Streams (PES) de video, audio y datos privados.

También como en MPEG-1, los paquetes PES empiezan por una cabecera de paquete, cuyo for-mato se describe en la figura 10.24 y en la tabla 10.6.

Figura 10.24 Cabecera de un PES MPEG-2

Tabla 10.6 Estructura de la cabecera del paquete MPEG-2

La parte sistema de MPEG-2 (ISO/IEC 13818-1), que define la organización del multiplexadoMPEG-2, prevé dos maneras diferentes de multiplexar estos PES para formar dos tipos de trenes,dependiendo de la aplicación a la cual esté enfocada.

Tren de programa (Program Stream). El tren "programa" de MPEG-2 se crea a partir de uno ovarias PES que deben obligatoriamente compartir el mismo reloj de referencia.

Paquete Número 1Start_code_prefixStart_code_prefixStart_code_prefix

Stream_idPacket_lengthPacket_length

PES-headersub-fields

Stuffing

Un byte

PES_scrmbling_control (2 bits)

flags de PES- header

3 bytes de flags

subcampos dependientesde flags

Campo Definición N de bits start_code_prefix código de inicio (00 00 01 hex) 24 string_id Identificación del PES 8 packet_length longitud del PES 16 PES_scrambling_control define si hay cifrado y su palabra de control 2 flags marcadores diversos 14

PES_header_length longitud de la parte restante de cabecera del PES (x+y) 8

PES_header_subfields campo variable que depende de los flags x bytes stuffing relleno y bytes



Este tipo de tren esta destinado a aplicaciones donde el dispositivo de almacenamiento o de trans-misión sea susceptible de introducir muy pocos errores (error free medium), como es el caso, porejemplo, de las aplicaciones multimedia en CD-ROM o disco duro. Aquí, estos paquetes puedenser relativamente largos (por ejemplo, 2.048 bytes) pero están organizados de manera similar aun tren "sistema" MPEG-1.

Tren de transporte (Transport stream). El tren transporte de MPEG-2 está principalmente desti-nado al transporte de programas de televisión a larga distancia sobre soportes o en medios sus-ceptibles de introducir un índice de errores bastante elevado (error prone medium); la longitud delos paquetes debe ser relativamente corta para permitir la introducción de los dispositivos decorrección de errores eficaces.

La longitud de los paquetes transporte de MPEG-2 ha sido fijada, por tanto, en 188 bytes, valorreservado especialmente para las emisiones vía satélite, cable o terrestres de la norma europeaDVB.

Este tipo de tren está destinado a combinar varios programas que no compartan forzosamente elmismo reloj de sistema (STC) en el interior de un mismo multiplexor.

Los diferentes PES (video, audio, etc.) que forman un programa dado, deben sin embargo com-partir el mismo reloj con el fin de poder ser sincronizados por el decodificador.

La figura 10.25 ilustra el proceso de creación de un tren de transporte MPEG-2.

Figura 10.25 Creación de un tren Transport MPEG-2 a partir de los PES que lo componen

Para el estándar MPEG-2 se utilizan cadenas elementales empaquetadas PES (Paquetized Ele-mentary Stream):Esta sintaxis fue definida por MPEG-2 para la división de las largas cadenaselementales de audio o video producidas por un codificador. Cada PES contiene una cabecera,

CP

CP=Cabecera de PESCT=Cabecera de paquetes de transporteDatos=Datos elementales: Audio, Vídeo, etc...CA=Campo de Adaptación

CT Datos CPOtros

paquetesde

transporte

CP Datos CP CPCA DatosOtros

paquetesde

transporte

CP CT Datos CPOtros

paquetesde

transporte

CP ......

PT1 PT2 PT3 PT4 PT5 PT6 PT7

188 bytes

Tren de paquetes

detransporte

184 bytes 184 bytes < 184 bytes 184 bytes

Paquete PES1 ( > 184 bytes) Paquete PES2 ( = 184 bytes)



header, con los datos necesarios para la descodificación. A partir de los PES se forman las cade-nas de transporte y programa definidas anteriormente.

• Formación del paquete de transporte MPEG-2

Un paquete "transport" de 188 bytes se compone de una cabecera de paquete (packet header), de4 bytes y de una "carga útil" (payload) de 184 bytes como máximo, eventualmente precedida deun campo de adaptación (adaptation field), como se muestra en la figura 10.26. La "carga útil"está formada por paquetes de trenes elementales (Packetized Elemetary Stream, PES) que com-ponen los programas de televisión transmitidos por el canal, así como cierto número de datosauxiliares que permiten al codificador no perderse por el tren de transporte MPEG-2.

Figura 10.26 Constitución del paquete transporte (caso general)

El formato de la cabecera del paquete de transporte se detalla en la figura 10.27, la figura 10.28 yla tabla 10.7.

Figura 10.27 Detalle de la cabecera del paquete transporte

La norma ISO/IEC 13818-1 especifica que un paquete de transporte dado sólo puede transportardatos procedentes de un sólo paquete PES, y que un paquete PES empieza obligatoriamente alprincipio de un paquete de transporte y se termina obligatoriamente al final de un paquete detransporte.

Debido a la longitud mucho más pequeña de los paquetes de transporte (184 bytes útiles) con res-pecto a los paquetes PES (por ejemplo, 2048 bytes), estos últimos deberán ser divididos en trozosde 184 bytes.

DatosCampo de

Adaptación(AF)

X bytes184-X4

188 bytes

Sync i-ésima

8 bits

Datos Contador de continuidad

1 1 1 13 2 2 4

Transport_error_indicatorPayload_unit_start_indicator

Transport_priorityAdaption_field_control

Transport_scrambling_control



Figura 10.28 Estructura completa de un paquete de transporte

Tabla 10.7 Estructura de una cabecera de paquete de transporte MPEG-2

Como la longitud de los paquetes PES en general no es múltiplo de 184 bytes, el último paquetede transporte de un paquete PES deberá empezar por un campo de adaptación (Adaptation Field,AF), cuya longitud será el complemento a 184 del número de bytes que queden por transmitirpara terminar este último paquete PES, como se muestra en la figura 10.29.

Sync8 Byte

Indicador deError de

TransporteIndicador de

ComienzoPrioridad deTransporte

PID Control deScrambling

Control delcampo de

AdaptaciónContador deContinuidad

Campo deAdaptación

Payload

3 1 1 1 13 2 2 4

Header Payload

Indicador deDiscontinuidad

Indicador deprioridad de

elementos dela cadena

5 flags Campoopcional

8 1 1 1 5

StuffingBytes

Indicador deAcceso

aleatorio

Longitud delCampo de

Adaptación

188 bytes

48 8

Extensión delCampo de

Adaptación

Datosprivados deTransporte

ContadordescenteOPCRPCR

48

Campo Definición (comentario) N° de bits sync_byte byte de sincronización 1000 0111 (47 hex) 8 ei transport_error_indicator (indica un error detectado mas

atrás) 1

pusi payload_unit_start_indicator (inicio de PES en el paquete) 1

tpr transport_priority (indicador de prioridad) 1 PID Packet IDentifier (identificación del paquete) 13 scr_flags transport_scrambling_flags (tipo de cifrado de

transporte) 2

af adaptation_field_flag (campo de adaptación en el paquete) 1

pf payload_flag (datos útiles en el paquete) 1 Cc continuity_counter (contador de continuidad entre

trozos) 4



Figura 10.29 Constitución del último paquete de transporte de un PES

Además de esta función de relleno, el campo de adaptación se utilizara también para la transmi-sión del reloj de referencia del programa (Program Clock Reference, PCR), cuya cadencia derepetición mínima es de 10 por segundo, así como diversos tipos de datos opcionales.

Un paquete de transporte eventualmente podrá estar constituido únicamente por un campo deadaptación, de 184 bytes en este caso concreto (transporte de datos privados, PCR, etc.).

La figura 10.30 ilustra el formato general del campo de adaptación, cuyo contenido se especificaen la tabla 10.8.

Figura 10.30 Detalle del campo de adaptación

Tabla 10.8 Constitución del campo de adaptación MPEG-2

Como ya se ha visto, un múltiplex de transporte MPEG-2 puede transportar varios programas,cada uno compuesto por uno o varios trenes elementales de paquetes (PES).

A fin de que el decodificador pueda orientarse dentro de esta variedad de paquetes, MPEG-2define cuatros tipos de tablas, que juntas constituyen la información especifica de los programas(Program Especific Information, PSI).

PES Final del PES

X

HPaquete deTransporte

AF

184-X

PES

Longitud del campo de adaptación

...Y

1 1 X Y-X-1 bytes

Y

Flags Campos opcionales Relleno

Campo Definición N° de bits adaptation_field_length longitud total en bytes, menos 1 (y) 8

flags marcadores que indican la información transportada 8

optional_fields campos opcionales de datos (x bytes) xx8 stuffing campo de relleno (y-1-x bytes de valor FF hex)



1.- Program association table (PAT). Esta tabla, cuya presencia es obligatoria, es transportadapor los paquetes cuyo indicador lleve el número 0 (PID= 0x0000). Su función es la de indi-car, para cada programa transportado por el múltiplex de transporte, la relación entre elnúmero de programa y el PID de los paquetes que transportan una tabla que indica los datosque identifican el programa (Program Map Table, PMT). La PAT siempre se transmite "deforma clara", aunque todos los programas estén cifrados.

2.- Program map table (PMT). Existe una tabla presente por cada programa en el múltiplex.Principalmente indica (sin cifrar) los PID de los trenes elementales que constituyen el pro-grama y, opcionalmente puede ser cifrada. Puede ser transportada por paquetes de PID arbi-traria, definidos por el emisor en la PAT (excepto 0x0000 y0x0001).

3.- Conditional access table (CAT). Esta tabla debe estar presente a partir del momento en queal menos un programa sea de acceso condicional. Se transporta por los paquetes dePID=0x0001 e indica los PID de los paquetes que transportan los EMM por uno o varios sis-temas de control de acceso (una de las informaciones necesarias para el descifrado de losprogramas de acceso condicional). La norma MPEG-2 prevé la posibilidad de añadir infor-maciones complementarias opcionales (DVB-SI, Service Information) que permiten que elreceptor se configure automáticamente, al tiempo que ofrece al usuario la posibilidad de"navegar" entre los numerosos servicios que se ofrecen.

4.- Tablas principales de DVB-SI:• Network information table (NIT). Esta tabla de información de red, cuyo contenido no está defi-

nido por MPEG, transporta informaciones especificas relativas a una red formada por varios canales físicos (por tanto, varios trenes de transporte independientes), tales como las frecuencias, los números de los canales de red utilizados en la configuración del receptor.

Esta tabla, si está presente, constituye por definición el programa 0 del múltiplex y es conside-rada como datos privados.

• Service description table (SDT). Esta tabla lista los nombres y otros parámetros asociados a cada servicio de un mismo múltiplex.

• Event information table (EIT). Esta tabla se utiliza para trasmitir información relativa a los acon-tecimientos en curso o que vendrán en el múltiplex MPEG recibido y, ocasionalmente, sobre unos múltiplex MPEG.

• Time and date table (TDT). Esta tabla se utiliza para poner en hora el reloj interno del receptor (decodificador).

También permite una serie de tablas opcionales, que se describen a continuación.• Tablas opcionales DVB-SI• Bouquet association table (BAT). Esta tabla se utiliza para agrupar la presentación al usuario de

ramilletes (bouquets) de servicios asociados. Un servicio particular puede pertenecer a uno o varios ramilletes.



• Running status table (RST). Esta tabla se trasmite para la actualización rápida de uno o varios acontecimientos, una sola vez, en el momento en que se produce un cambio (a diferencia de otras tablas que se tramiten de forma repetitiva).

• Stuffing tables (ST). Estas tablas de "relleno" se utilizan, por ejemplo para invalidar tablas que ya no sirven.

La frecuencia de repetición de las tablas no viene impuesta por la norma, no obstante, debe sersuficiente (de 10 a 50 veces por segundo) para que permita que el decodificador acceda con sufi-ciente rapidez al programa buscado, especialmente, cuando se pone en marcha.

La información de algunas tablas (PAT, PMT) podrán eventualmente ser almacenadas en unamemoria no volátil del decodificador para permitir un acceso más rápido tras la puesta en mar-cha. Posteriormente, esta memoria deberá actualizarse cuando se produzcan modificacionesesporádicas en el contenido del múltiplex.

Cada tabla está constituida, según su importancia, por una o varias secciones (256 como máximo,con una longitud máxima de 1024 bytes, salvo para la tabla private que puede alcanzar los 4026bytes).

La figura 10.31 muestra la manera en que utilizan las tablas constituyendo una PSI.

Figura 10.31 Estructura PSI

Programa 0

Tabla de asosiación de

programas(PID 0)

16Programa 1 22Programa 3 33

Programa k 55

Datosprivados

de red

Tabla deinformación

de red

Stream 1 54VídeoStream 2 48AudioStream 3 49Audio

Stream k Datos

Stream 1 54VídeoStream 2 48AudioStream 3 49Audio

Stream k Datos

Tablas de aplicaciónde programa (PMT)

Prog 1PMT

Prog 3PMTPAT Prog 1

Audio 2EMM Prog 3Audio 2

Prog 3Vídeo 1

Prog 3Vídeo 1

Prog 1Vídeo 1

Prog 3Audio 1

Prog 3Vídeo 1

0 22 33 1 49 82 19 19 54 81 19

Datos de accesocondicional

Tabla de accesocondicional (PID 1)



Al contrario que en los PES, las secciones no empiezan y acaban forzosamente con un paquete detransporte. Cuando una sección o un PES empieza en un paquete, el indicadorpayload_unit_star_indicator (PUSI) se pone a "1".

Cuando se trata de una sección, el paquete puede empezar al final de otra sección, precedida o node un campo de adaptación (adaptation_field). El primer byte de la "carga útil" (payload) es unindicador llamado pointer_field el que da el desplazamiento (offset) del comienzo de la nuevasección con respecto a este byte.

La figura 10.32 ilustra el caso donde una sección empieza en un paquete de transporte, despuésde un campo de adaptación (AF) y el final de una sección anterior.

Figura 10.32 Caso general del comienzo de sección en un paquete de transporte

Las principales etapas que hay que seguir para encontrar un programa o servicio en un múltiplexde transporte MPEG-2, una vez que el múltiplex ha sido capturado (sintonizado en un canal).

• Formato del MPEG-4

El estándar MPEG difiere sustancialmente tal y como se indicó anteriormente. Por ello especificaun Formato Binario para Escenas, BIFS, BInary Format for Scenes que se utiliza para describir lainformación de la composición de la escena, que consiste en las localizaciones espaciales y tem-porales de los objetos en las escenas, junto con sus atributos y comportamientos. Los elementosde la escena y las relaciones entre ellos forman el grafo de la escena, que debe codificarse para latransmisión. Los elementos fundamentales del grafo de la escena son los nodos que describen lasprimitivas audiovisuales y sus atributos, junto con la estructura del propio grafo de la escena.

La descripción de las escenas se estructura en árbol basándose en la tecnología VRML (VirtualReality Modeling Language).. El lenguaje VRML, diseñado como un formato de fichero paradescribir modelos y escenas 3D (mundos en su terminilogía). Sin embargo, carece de algunascaracterísticas necesarias para diversas aplicaciones multimedia a las que se aplica el MPEG-4.En particular, el soporte para vídeo y audio natural es básico. Por ejemplo, la secuenciación delos objetos de audio o vídeo no está soportada. Además la especificación del modelo de tempori-zación es pobre, implicando que no puede garantizarse la sincronización en una escena con múl-tiples tipos de medios. Además, los mundos VRML son a menudo muy grandes. Lasanimaciones que tardan alrededor de 30 segundos consumen típicamente varios megabytes. Lapotencia de VRML radica en sus capacidades de descripción del grafo de la escena y sobre ella seha construido la base con la que se ha construido la descripción de la escena en MPEG-4.

Point_field

H AF

Comienzo de sección



El BIFS incluye soporte para casi todos los nodos en las especificaciones de VRML. De hecho,BIFS es esencialmente un superconjunto de VRML, aunque hay algunas excepciones. Por ejem-plo no soporta el uso de lenguaje Java en los nodos Script, sólo ECMAScript. Sin embargo, BIFSamplía significativamente las capacidades de VRML de manera que permite un rango de aplica-ciones mucho mayor. Obsérvese que una diferencia fundamental entre los dos es que BIFS tieneformato binario mientras que VRML es tipo texto. Así, aunque es posible diseñar escenas quesean compatibles con BIFS y VRML, es necesario transcodificar los formatos.

Seguidamente se destacan las funcionalidades de BIFS que se añaden al conjunto básico delVRML.

1.- Formato binario comprimido: BIFS describe la información del grafo de la escena con unaeficiente representación binaria. La codificación puede ser con o sin pérdidas. La eficienciade la codificación se debe a un conjunto de técnicas clásicas de compresión y algunos nue-vos. El conocimiento del contexto se explota ampliamente en BIFS. Esta técnica se basa enel hecho de que dado algún grafo de la escena los datos han sido recibidos previamente,entonces es posible anticipar el tipo y el formato de los datos para recibirlos.

2.- Secuenciación. BIFS se diseñó tal que la escena puede transmitirse como un escena inicialseguida de las modificaciones a la misma. Para escenas dinámicas que cambian con eltiempo esto repercute en una gran mejora en el uso de la memoria así como en reducir lalatencia respecto a las escenas VRML equivalentes. El protocolo BIFS Command permitereemplazar la escena entera, sumar, eliminar o reemplazar los nodos y los elementos delentorno en el grafo de la escena así como modificar las propiedades de la escena.

3.- Animación. Se diseñó un segundo protocolo de secuenciación, denominado BIFS Anim,para proporcionar mecanismos para la animación contínua

4.- Primitivas 2D. BIFS incluye soporte nativo para las escenas 2D. Esto facilita a la creaciónde contenidos con escenas de baja complejidad, incluyendo la televisión tradicional y lasindustrias multimedia.

5.- Audio realzado. VRML ofrece un único soporte de audio. Este soporte ha sido mejorado enel MPEG-4. BIFS proporciona la noción de un grafo de escenario de audio en la que puedenmezclarse las fuentes de audio, incluyendo las secuenciaciones. También proporciona uninterface de nodos para varios objetos de audio MPEG-4. El contenido de audio puedeincluso procesarse y transformarse con procedimientos especiales para producir diferentesefectos de sonido.

6.- Animación Facial. BIFS proporciona soporte a nivel de escena para la animación facial en eldecodificador MPEG-4. Un conjunto especial de nodos BIFS exponen las propiedades delos rostros animados



10.6.3 FORMATO DE LOS ARCHIVOS QUICKTIME. MOVUn archivo QuickTime es simplemente una colección de átomos. QuickTime no impone ningunanorma sobre el orden de dichos átomos.

La tabla 10.9 muestra el esquema de una archivo Quicktime.

Tabla 10.9 Estructura del archivo QuickTime.

En los sistemas en los que se soportan extensiones de archivo Quicktime recibe normalmente laextensión mov. En las plataformas Macintosh tienen un tipo de archivo

Cada átomo pertenece a un tipo determinado. Algunos átomos se consideran tipos básicos y for-man la estructura dentro de otros átomos que están almacenados. La tabla 10.10 muestra los tiposde átomos básicos soportados.

Tabla 10.10 Tipos de átomos básicos.

Aunque es verdad que QuickTime no impone un orden estricto sobre los átomos del vídeo, fre-cuentemente es conveniente establecerlo si los átomos de película aparecen cerca del principiodel fichero. Por ejemplo, una aplicación que reproduce una película sobre una red necesitaríatener acceso a la película completa todo el tiempo, Si el átomo de película se almacena al princi-pio del fichero, la aplicación puede utilizar los meta datos para entender los contenidos de la pelí-

Datos del átomo de película Bytes Tamaño del Átomo 4 Type = 'mdat' 4 Datos Variable

M

Átomo de película 4 Tamaño del Átomo 4 Type = 'moov' Variable Datos

Tipo de átomo Utilización

'free' Espacio no utilizado disponible en el fichero. 'skip' Espacio no utilizado disponible en el fichero.

'wide' Espacio reservado — puede sobreescribirse mediante un archivo de tamaño extendido.

'pnot' Referencia a datos de previsionado de la película

‘moov' Recurso de película – los datos sobre la película (número y tipo de pista, localización de los datos muestras, etc.)

'mdat' Datos de película — usualmente estos datos pueden interpretarse sólo utilizando los recursos de la película.



cula mientras se adquiere a lo largo de la red. Esto puede permitir que la aplicación reproduzca lapelícula mientras que se descarga.

Seguidamente se describen brevemente los fundamentales. • Átomos de espacio libre.

Tanto los átomos free como skip designan espacio no utilizado en el archivo de datos de película.Estos átomos constan sólo de una cabecera que indica el tamaño del átomo y los campos tipo. Acontinuación contiene el número de bytes de espacio libre. Cuando se lee una película Quicktimela aplicación puede saltar estos átomos de forma segura. Cuando se escribe o se actualiza la pelí-cula se puede reutilizar el espacio asociado con estos tipos de átomo.

El átomo wide consta sólo de tipo y tamaño de campo. Esto ocupa 8 bytes, espacio suficientepara añadir un campo tamaño extendido a la cabecera del átomo siguiente. Si un átomo crece yexcede los 232 bytes, y es precedido por un átomo wide, puede crearse una nueva cabecera deátomo que contenga un campo de tamaño extendido sobrescribiendo al átomo wide.

• Átomos de datos de película.

Como en los átomos anteriores, la estructura de los átomos de datos de película es bastante senci-lla. Constan de una cabecera que indica el tamaño del átomo y los campos tipo seguidos por losdatos de la película. La aplicación puede entender los datos sin más que consultar los datos alma-cenados. Este átomo puede ser bastante grande, y puede exceder los 232 bytes en cuyo caso elcampo de tamaño se colocará a 1 y la cabecera contendrá un tamaño de campo extendido a 64bits.

• Átomos de previsión, preview.

Estos átomos contienen la información que permite encontrar el previsionado o póster de la ima-gen asociada a la película La tabla 10.11 muestra la capa de un átomo preview.

Tabla 10.11 Capa de un átomo preview.

El átomo de previsualización tiene un valor del tipo de átomo 'pnot' y le sigue su átomo de cabe-cera que contiene los siguientes campos:

Descripción de campo

Size. Tamaño. Es un entero de 32-bit que especifica el número de bytes en este átomo preview.

Átomo preview Bytes Tamaño del Átomo 4 Type = 'pnot' 4 Modificación de datos 4 Número de versión 2 Tipo del Átomo 4 Índice del Átomo 2



Type. Tipo. Es un entero de 32-bit que identifica el tipo del átomo, este campo debe ponerse a'pnot'.

Modification date. Datos de modificación. Es un entero sin signo de 32-bit que contiene un datoque indica cuando fue la última actualización de la previsualización.

Version number. Es un entero de 16-bit que debe colocarse a 0.

Atom type. Es un entero de 32 bits que indica el tipo de átomo que contiene los datos de previsua-lización. Normalmente se coloca a 'PICT' para indicar que es una imagen QuickDraw.

Atom index Es un entero de 16-bit que identifica qué átomo del tipo especificado se utiliza en leprevisualización. Normalmente este campo es colocado a 1 para indicar que se usará el primerátomo del tipo especificado.

Los átomos de película de QuickTime actúan como contendores para la información que describelos datos de la película. Esta información, o meta-datos, se almacena en varios tipos diferentes deátomos. El átomo de película es esencialmente un contenedor de otros átomos. En el nivel másalto, los átomos de película generalmente contienen átomos de seguimiento, y en el nivel menorlos átomos que contienen los datos reales, normalmente en forma de tabla o secuencia de datos.Los átomos de seguimiento contienen por ejemplo los átomos de edición, que contienen unátomo que contiene la denominada lista de edición de átomos. La figura 10.33 muestra elesquema de una película Quicktime con una única película. Cada caja anidada representa unátomo que pertenece a su átomo padre.

Debe tenerse en cuenta que esta descripción corresponde al estándar. Si se trabaja con el APIQuicktime no es necesario considerar los átomos ya que puede utilizarse la funciones de átomospara crear los contenedores de átomos, sumarlos y eliminarlos de los contenedores de átomos,buscar átomos en los contenedores de átomos y recuperar datos a partir de los átomos.

10.7 LA EDICIÓN DE VÍDEO Y EL MERCADO DE CONSUMO

En 1996, Sony y Panasonic presentaron el primer formato DV y cambiaron para siempre el videoprofesional y de consumo. Por primera vez, la grabación de video con calidad digital estaba dis-ponible a precios accesibles. El formato DV era más pequeño que el MotionJPEG y éste tomabavideo directamente de la cinta con toda conversión análoga a digital realizada por circuitos de lacámara de vídeo digital. Además, las cámaras DV incorporaban una interfase completamentedigital llamada IEEE-1394, también iLINK o Firewire, para transferir el video y el audio pura-mente digital directamente al PC con sincronía perfecta. Otras mejoras en la óptica de la cámaray CCDs produjeron un salto significativo en la calidad desde las fuentes de estándares analógicosS-video/Hi8.

El resultado fue la digitalización pura en la toma, edición y distribución, alcanzable a un módicoprecio. El DV estándar eliminó las conversiones analógico-digital- analógico previamente reque-



ridas con MotionJPEG y disminuyó la velocidad de bits de la secuencia de video a un valor de3.7MB por segundo en lugar de los 7MB por segundo del MotionJPEG de similar calidad. Dadoque la conversión analógico -digital y digital- analógico reduce la calidad, el formato DV man-tiene la más alta calidad posible.

Figura 10.33 Esquema de una película Quicktime con una única película.



La baja velocidad de datos implica que no se debe gastar demasiado en configurar el sistema deedición DV, porque pueden usarse componentes de bajo costo. Más aún, como los profesionalesy utilizan cámaras DV y cámaras analógicas, parece tener mas sentido editar los contenidos ana-lógicos y DV juntos en formato DV. Esto mantiene los contenidos digitales puros y reduce eltamaño de la compresión del video analógico en el sistema.

Con la aceptación del formato de películas DVD y la televisión Directa Digital en el mercado deconsumo, el formato de compresión MPEG 2 fue considerado como un formato posible de edi-ción de video. Esto parece lógico porque ofrece una calidad superior de video comparado con lascintas corrientes de VHS, emisión de televisión y hasta discos láser. Un obstáculo significativodel MPEG-2 es que, a diferencia del DV donde la velocidad de datos y la calidad de imagen sonconsistentes a través de todas las implementaciones, la calidad de imagen del MPEG-2 puedevariar significativamente de acuerdo con el sistema de codificación empleado y la capacidad deprocesamiento puesto a su disposición.

Actualmente los sistemas de edición MPEG-2 utilizan Main Profile a Main Level (MP &ML,IBP) o Simple Profile a Main Level (SP &ML,IP). La más alta calidad al más bajo ancho debanda es MP & ML. El siguiente paso es SP &ML. SP &ML, usa marcos I y P solamente, nece-sitan un mayor ancho de banda y agrega una perdida innecesaria. Como el marco P no es unaimagen completa, el decodificador MPEG-2 y el software de edición deben reconstruir una ima-gen completa a partir del ultimo marco I y la porción cambiada representada en el marco P. Unmarco típico B o P contiene solamente un 5% de los datos encontrados en un marco I. El marcoreconstruido pocas veces reproduce la misma calidad que el marco I completo. Es como miraruna impresión fotográfica. La imagen fotográfica en si misma es de alta calidad pero si se haceuna copia o se edita la foto no se parte de la fotografía sino que se va al negativo para lograr unaóptima calidad. En el caso de la edición MPEG-2 IBP, el negativo no existe y nunca fue tomadoen esa forma.

Para lograr la mejor calidad de salida es importante minimizar el número de veces que se con-vierte el material inicial a otro formato en un proceso de edición. Cada paso innecesario analó-gico-digital o digital- analógico o bien la transcodificación entre formatos de compresión,produce un decrecimiento de la calidad. Además, el esquema de compresión debe guardardurante el proceso de edición suficientes datos disponibles para conservar la integridad de la ima-gen.

La mejor opción para conseguir la más alta calidad es mantener la información dentro del mismoformato de adquisición - si la fuente es digital, mantener el formato digital a través de todo elproceso de edición - y mantener el mismo formato digital durante todo el proceso.

tema 10 compresión de vídeo - ocw uned

Documents