Tema10 PDF

Programa Oficial de Postgrado:
Master en Comunicaciones, Redes y Gestin de Contenidos

TECNOLOGA DE LOS CONTENIDOS MULTIMEDIA

Optativa de 2 cuatrimestre

TEMA 10
Compresin de Vdeo

TEMA 10
Compresin de Vdeo
10.1 INTRODUCCIN A LA COMPRESIN DE VDEO.
La compresin de sonido y de vdeo es hoy en da una necesidad conocida y las herramientas que
se han desarrollado a lo largo de los ltimos aos han ido apareciendo en el mercado de consumo
con intensidad relevante. La ventaja fundamental de la compresin va ms all del mero ahorro
en los dispositivos de almacenamiento. Su mayor inters prctico se centra en las comunicacio-
nes, especialmente mediante Internet, ya que influye decisivamente en la posibilidad de transferir
elementos de audio y/o video mediante este medio.
La tecnologa de la compresin de vdeo es el factor fundamental para la transmisin de vdeo
mediante un canal de comunicacin con un coste aceptable. Tambin es bsica para la autora
multimedia, el entretenimiento, los sistemas educacionales, la televisin digital por satlite, etc.
Por otro lado, la historia de la tecnologa de compresin 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 Comn de Intermediacin, contendra 352 x 288 pixels de
luminancia, 176 x 144 de crominancia R-Y y 176 x 144 de crominancia B-Y. A 30 frames en
NTSC (25 en PAL) por segundo con 8 bits de informacin por pxel, esto es alrededor de 36 Mb
por segundo, y transmitirlos por un canal de comunicaciones RDSI (RDSI, Red Digital de Servi-
cios Integrales en Espaa) a 128 kb por segundo es un reto formidable. Pretenderlo en tiempo
real manteniendo la sincronizacin del audio y el video es todava ms difcil.
En la figura 10.1 se muestra un diagrama especialmente significativo, que ilustra cmo la historia
de la videoconferencia est estrechamente relacionada con la historia de las tecnologas de com-
presin y los desarrollos industriales relacionados con ella, tanto hardware como software.
TEMA 10. COMPRESIN DE VDEO UNED - CURSO 2007-2008
10.2 Tecnologa de los Contenidos Multimedia
Figura 10.1 Necesidades de ancho de banda para el transporte de video a lo largo de los aos.
Como puede observarse durante la dcada de los 80 se produjo un extraordinario descenso en los
requerimientos necesarios de ancho de banda para obtener una secuencia de video de calidad
aceptable. Tras esta dcada, el ancho de banda necesario para la transmisin de video est alrede-
dor de 1.5 Megabits por segundo. Hoy en da, la mayora de los usuarios encuentran suficiente-
mente satisfactoria una velocidad de 384KB por segundo, y se han producido mejoras
extraordinariamente significativas tanto en los algoritmos como en las capacidades de los dispo-
sitivos hardware diseados para ejecutar dichos algoritmos.
Por otro lado durante este periodo de tiempo tambin se han desarrollado importantes mejoras en
el precio y en la capacidad de las lneas de comunicacin que han permitido transportar las
secuencias digitales de bits necesarias para conseguir calidades relativamente buenas tanto de
video como de videoconferencia.
Con todo ello puede establecerse que la convergencia entre la capacidad de las comunicaciones
con la tecnologa de compresin han permitido el desarrollo del video digital y la entrada masiva
de la industria y el consumo en este campo.
Con el fin de comprender el coste real de la compresin de video se analiza el siguiente ejemplo.
Considrese la compresin del video NTSC, que es el estndar de las emisiones de televisin,
VCR y videocmaras en USA. El estndar en Europa y Asia es PAL o C-CAM. En cualquier
caso el clculo es el mismo salvo los datos.
Si se digitaliza una seal de video NTSC y cada frame se digitalizar. Como hay 30 frames por
segundo se tendra una secuencia de alrededor de 24.9 MB por segundo o 200 Megabits por
segundo:
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
A
n
c
h
o

d
e

B
a
n
d
a
1970 1980 1990 2000
c
a
p
a
c
id
a
d
1.5 Mbps
768 Mbps
Requerimientos
Tecnologa de los Contenidos Multimedia 10.3
Es recomendable que el lector realice los clculos para el sistema PAL con los datos indicados en
el captulo anterior.
Obviamente esto excede con mucho la capacidad de la mayora de las lneas de comunicacin.
Por ejemplo la lnea T1, que en general es considerada como un acceso a Internet de alta veloci-
dad, slo es capaz de transmitir 1.54 Mbits/sec. Puede observarse que la compresin es funda-
mental, al igual que se indic en el ejemplo anterior de la videoconferencia.
En conclusin, puede considerarse que tpicamente es necesaria una compresin de 500, 1000 o
2000 a 1 para que sea posible la transmisin de una secuencia de video mediante las lneas de
comunicacin disponibles. Es imprescindible comprimir la seal.
Anlogamente sucede en la transmisin de vdeo con televisin de alta definicin, o HDTV
(High Definition TV). Un formato de vdeo HDTV habitual se escanea progresivamente con 720
1280 pixels/frame, con una seal de vdeo a 60 frames por segundo, con 24 bits/pxel, 8 bits para
el 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 transmitir
cerca de 20 Mb por segundo con un ancho de banda de 6 MHz por cada canal de televisin. De
nuevo se observa la necesidad de utilizar potentes tcnicas de compresin para comprimir en este
caso con un factor de 70, equivalente a 0.35 bits/pixel, para enviar por un canal de 20 MB por
segundo la informacin con una velocidad de fila de 1.3 Gb por segundo. El estndar de compre-
sin de vdeo MPEG-2 es el utilizado para la compresin de vdeo HDTV.
En conclusin la compresin de vdeo ha sido un instrumento esencial en diversas aplicaciones,
entre las que destacan la televisin digital, los discos de vdeo digital, la telefona con vdeo y las
secuencias de vdeo transportadas mediante Internet o enlaces sin cables (wireless). Adems la
compresin ha sido un elemento crucial para superar el problema de la limitacin en el ancho de
banda, y tambin en la capacidad de almacenamiento.
10.2 COMPRESIN / DESCOMPRESIN: CARACTERSTICAS Y RESTRICCIONES.
La compresin y la descompresin se realiza mediante un codificador y un decodificador respec-
tivamente, que en la terminologa del rea suele denominarse Codec. Este elemento no es ms
que una funcin, que toma una secuencia de bits y da como salida una secuencia de datos. La
figura 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 para
datos. Por otro lado debe tenerse en cuenta que hay multitud de restricciones en el diseo lo que
tambin implica la existencia de multiples Codecs.
Prcticamente existen tantos CODECs para la compresin de audio y video como investigadores
en el rea. Las elecciones posibles son mltiples y las aplicaciones son an ms.
Figura 10.2 Codec. Compresin / descompresin.
Otro aspecto de especial inters es el hecho de que un Codec es una funcin, y no est limitado a
ningn aspecto en particular, ni es un dispositivo en particular. Por ejemplo puede ser una simple
tarjeta en un computador personal, o un chip en una placa madre, o una funcin software que se
ejecute en un computador.
Un primer aspecto a considerar es la compresin genrica multimedia. En general en los entornos
multimedia se hace uso de los conocimientos fisiolgicos sobre los sistemas de visin y audicin
humana. Esto es especialmente til en el diseo de los Codecs que aprovechan las facultades ms
relevantes de los sistemas auditivos. Por ejemplo, es conocido que el ojo humano es mucho ms
sensible al brillo y mucho menos sensible a la variacin del color. Por ello en la compresin de
video se presta mucha ms atencin a los elementos que tratan el brillo y mucha menos a los de
color. Anlogamente se conoce que el odo humano no puede or algunas frecuencias y que otras
no son agradables de escuchar. Por ello las seales con estas frecuencias se digitalizan con menos
precisin o incluso se eliminan completamente en el proceso de compresin.
Tanto cuando se selecciona un Codec como cuando se disea es fundamental considerar las res-
tricciones. Como todo usuario de Internet sabe, en el entorno de las comunicaciones es muy
importante disponer de Codecs adecuados. Es importante realizar las comunicaciones sin que el
usuario tenga que preocuparse de los detalles del hardware en cada extremo de la comunicacin y
es necesario que independientemente del esquema que se utilice en la compresin el otro lado de
la comunicacin pueda descomprimir. Sin embargo, las restricciones impiden que haya un nico
Codec universal.
Por ejemplo, en la compresin de video siempre existe una cuestin que debe tenerse en cuenta:
cuntos bits por pxel se estn suponiendo en la compresin. En el ejemplo de la compresin
NTSC anteriormente comentado se ha supuesto que hay 8 bits por pxel para los pixels de lumi-
nancia y tambin 8 para los de crominancia. Sin embargo, si la capacidad de memoria es una res-
triccin debera almacenarse todo en un byte.
CODEC
Datos de Entrada Datos de Salida
Audio
Voz
Video
Datos
Restricciones de diseo
Una de las caractersticas principales de los Codecs es su complejidad computacional. Los algo-
ritmos muy complejos pueden necesitar una potencia de clculo que no est disponible en el sis-
tema utilizado.
Es evidente la importancia de las restricciones en el diseo del Codec, pero la ms importante es
que el Codec pueda realizar su tarea con una complejidad computacional adecuada y adaptada a
la potencia de clculo disponible. Sera absurdo disear un Codec que necesite dos supercompu-
tadoras tipo Cray o un clster cuando la aplicacin se desarroll en el entorno de la informtica
de consumo. Adems es evidente que debe haber sintona entre la potencia de clculo y las exi-
gencias del algoritmo. Por ejemplo los algoritmos de compresin de voz para telefona sin cable
deben ejecutarse en procesadores de seal que sean compatibles con las caractersticas de la tec-
nologa sin cables (wireless), como por ejemplo un bajo consumo de potencia para conseguir una
larga vida de la batera.
Otra restriccin importante para las trasmisiones en tiempo real es la razn de compresin, aun-
que con frecuencia es una de las ms ignoradas. Sin embargo es obvio que la salida del Codec
tiene 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 de
bajo coste en tiempo real ya que la salida del MPEG2 es de 6Mb por segundo, 6000 kb por
segundo. Esta es la velocidad de la televisin MPEG2 por satlite, mientras que la de por ejem-
plo un CD-ROM I/O es 1.5 Mb/s (Mb=Megabits) por segundo en aplicaciones multimedia que
no tiene mucha aplicacin para los sistemas de comunicacin basados en la telefona (que dispo-
nen de 9.6 a 128 kb por segundo). Por tanto es evidente que un Codec optimizado para el ancho
de banda de la televisin MPEG2 por satlite ofrece mayor calidad de audio y video que uno
optimizado para videoconferencia sobre lnea RDSI a 128 kb por segundo.
La restriccin ms evidente es que la calidad de la salida del Codec debe ser aceptable. Sin
embargo, esta restriccin es ignorada con frecuencia, a costa del sufrido observador del resul-
tado. Si se trata de comunicaciones y transmisin de voz es evidente que el Codec slo ser ade-
cuado si lo escuchado es inteligible y el hablante reconocible, y lo mismo sucede en la
codificacin de video, aunque es habitual que en las videoconferencias las deficiencias en la
salida no sean fuertemente rechazadas por el usuario. Afortunadamente la calidad es un factor
que se beneficia de las continuas mejoras que se realizan tanto en los algoritmos como en la
potencia de clculo.
Otro aspecto a considerar es la simetra. En el entorno de las comunicaciones bidireccionales en
tiempo real, los usuarios suelen enviar y recibir secuencias simultneamente a ambos lados de la
lnea de codificacin, pinsese por ejemplo en la videoconferencia. Esta es una situacin muy
diferente al paradigma tpico de los desarrollos multimedia sobre PC. Por ello en estas aplicacio-
nes es necesario que el Codec realice la compresin y la descompresin de forma balanceada, es
decir, utilice el mismo tiempo para realizar la compresin y la descompresin. Evidentemente
este aspecto no tiene inters en las aplicaciones unidireccionales, en las que se almacenan las
secuencias de salida del Codec y posteriormente se envan. Adems, los algoritmos basados en el
modelo consistente en codificar una vez lentamente y decodificar muchas veces rpidamente no
son apropiados para la videoconferencia. Sin embargo, los algoritmos con simplicidad suficiente
para descodificar pueden implementarse en un host PC, mientras que la codificacin normal-
mente se realiza sobre dispositivos dedicados o DSP de propsito general. Este hecho tambin se
est convirtiendo cada vez ms en un paradigma para los MPEG multimedia.
Un factor importante a tener en cuenta es la latencia. La latencia es un trmino tcnico que indica
retardo o retraso, relacionado con el manejo de los bits de forma agrupada. Si se agrupa una
muestra grande de datos y se comprime se pueden analizar los datos y tratarlos con un algoritmo
para comprimir un grupo de datos. Hacer esto es mucho ms eficiente que tratar cada punto indi-
vidualmente, obsrvese que por ejemplo se pueden evitar redundancias. Sin embargo al agrupar
un grupo de datos normalmente aparece un gran retardo debido al tiempo utilizado para agrupar
los datos. Por ejemplo, si se agrupan 30 milisegundos de datos de voz y posteriormente se decide
cmo comprimirlos se est introduciendo al menos un retardo de 30 milisegundos en el lado de la
recepcin y otros 30 milisegundos en el de la emisin. Por tanto, en una comunicacin en tiempo
real se estn introduciendo al menos 60 milisegundos, lo que es muy significativo en los entornos
de comunicacin bidireccionales en tiempo real. Cuando se tienen diferentes cantidades de
retardo en el video y en el audio se empieza a perder la sincronizacin, lo que es molesto e
inaceptable. Por tanto la latencia es un problema serio en las aplicaciones de videoconferencia
pero no es un problema para las que utilizan almacenamiento para la posterior comunicacin,
como por ejemplo las pelculas en DVD.
Hay aplicaciones, especialmente en la compresin de datos, en las que es muy importante dispo-
ner de un entorno "sin prdidas", lossless, es decir, es importante que al descomprimir los datos
se obtenga una reproduccin exacta de la seal original.
La compresin sin prdidas se considera un proceso reversible en el que se puede reconstruir per-
fectamente la secuencia de datos de imgenes o audio. Ejemplos de esta caracterstica son las tc-
nicas de codificacin vectorial, codificacin de entropa o codificacin de longitud variable
(como los cdigos de Huffman).
La compresin con prdidas hace uso de las caractersticas fisiolgicas y especialmente los lmi-
tes de los sistemas sensoriales humanos, que permiten eliminar de las secuencias de datos seales
de varias frecuencias y amplitudes no detectables.
La codificacin psicofsica produce tcnicas de compresin que reducen el nmero de bits nece-
sarios para reproducir los sonidos o imgenes, pero la reconstruccin nunca es el 100% del origi-
nal. Evidentemente las tcnicas sin prdidas seran inapropiadas para la compresin de datos
cuando cada bit cuenta, como por ejemplo en bases de datos en las que cada bit es importante o
en la transmisin de imgenes mdicas.
Las tcnicas de compresin sin prdidas estn muy limitadas, en general a una razn de compre-
sin de 4 a 1, mientras que las tcnicas con prdidas pueden ofrecer razones de 200 a 1.
Por ltimo una restriccin evidente es el coste. Cuando se elige un Codec es importante conside-
rar los costes tanto de software como de hardware. Cualquier algoritmo de compresin de video
representa un compromiso de diseo entre la potencia de clculo requerida para implementar la
compresin, la potencia de clculo necesaria para la descompresin, la calidad de los datos des-
comprimidos en relacin con los datos de entrada, la razn de compresin y el retardo debido al
esquema de compresin. Por ejemplo, la razn de compresin ms alta posible se obtendra con
un coste de hardware elevado o si no se tendra una muy pobre calidad de imagen en el receptor.
Sin embargo, como el coste de un equipo es un factor determinante obtener la mayor compresin
de los datos de vdeo posible con la mayor calidad de vdeo no es una solucin adecuada, por lo
el mercado presenta una amplia gama de posibilidades que sern ms o menos adecuadas en fun-
cin de la aplicacin que vaya a ser desarrollada en las mismas.
Para la videoconferencia corporativa la seleccin de un esquema de compresin con una calidad
de imagen razonable pero no grande es menos sensible al precio que una aplicacin de juegos
multimedia, en la que el coste es fundamental. El punto clave en la videoconferencia es un algo-
ritmo de compresin que produzca una secuencia con velocidad compatible con el canal de
comunicacin. Y adems, como se ha dicho, la compresin debe tener latencia pequea para
mantener la sincronizacin y que la comunicacin sea en vivo.
Sin embargo, para los reproductores de CD-ROM el objetivo principal es que la descompresin
sea de bajo coste, que suele conseguirse utilizando slo software, que puede producir video
basndose en velocidades de datos fuera del reproductor de CD-ROM. Como el material se com-
prime slo una vez, el tiempo y el coste de la compresin no son aspectos primordiales. Lo
mismo ocurre en la distribucin de video por demanda, se comprime slo una vez y se trasmite
por cable o satlite, descomprimindose finalmente en el receptor.
10.3 TCNICAS DE COMPRESIN
El esquema general de compresin de vdeo consta de tres pasos bsicos:
1.- Anlisis de la seal.
Se realizan medidas sobre la secuencia de vdeo de entrada, se calculan los errores de pre-
diccin y se realizan las transformadas (operaciones matemticas) del dominio temporal al
dominio de la frecuencia, obteniendo los coeficientes asociados a dicha transformada. La
compresin de datos siempre se realiza haciendo uso de un algoritmo de procesamiento
digital de seales. Seguidamente se divide la seal en subbandas y se realiza un anlisis de
correlacin. 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-
cin de la seal, salvo errores de redondeo, por lo que no se realiza ninguna reduccin de
datos.
2.- Cuantificacin
En este paso es dnde se realizan la mayora de las tcnicas de compresin porque el cuanti-
ficador puede eliminar valores que representan informacin intil. Este paso suele implicar
prdidas en la informacin para recuperar la seal, pero tambin se pueden definir tcnicas
sin prdidas con razones de compresin menores.
3.- Codificacin de longitud variable o codificacin por entropa.
A cada evento se le asigna un cdigo con un nmero de bits variable. En general suceden
eventos que tienen cdigos con pocos bits, slo los eventos poco comunes tienen cdigos
con muchos bits. Es de esperar que la longitud de cdigo en promedio sea menor que la lon-
gitud de un cdigo fijo que sera necesario sin esta disposicin. Esto suele realizarse
mediante el cdigo de Huffman.
En general pueden considerarse dos aproximaciones para implementar un Codec. El primero se
conoce como Procesamiento de Seal Nativo, Native Signal Processing. Generalmente est
basado en un Host en el que se utiliza un procesador, como por ejemplo un Pentium, una Sun
Spark Station o un procesador HP, con un Codec software. La caracterstica bsica en este tipo de
compresin es que el procesador es de propsito general y el Codec es slo software, lo que per-
mite que sea una implementacin de bajo coste y la integracin y el desarrollo del software es
ms general y sencillo.
La segunda aproximacin es utilizar un dispositivo dedicado, tpicamente un chip que ha sido
diseado y optimizado para la compresin de video y/o audio. Estos chips son conocidos como
Procesadores Digital de Seales, DSP (Digital Signal Processors), y ofrecen prestaciones mucho
mayores. Adems libera a la CPU de la tarea de compresin, por lo que puede ejecutar otras apli-
caciones, y es compatible con dispositivos no conectados e individuales.
Las tecnologas utilizadas para la compresin de video son muy diversas pero en general pueden
establecerse cuatro aproximaciones para implementar la compresin de un frame de video:
Transformada del Coseno Discreta, (DCT, Discrete Cosine Transformation).
Cuantificacin vectorial, (VQ, vector quantization).
Compresin fractal.
Transformada Wavelet Discreta, (DWT, Discrete Wavelet Transform)
La DCT es la base fundamental para la mayora de los protocolos de comunicacin y tambin la
mayora de los estndares que se utilizan hoy en da, como por ejemplo JPEG 2000, MPEG-1 y
MPEG-2, H.26X, y prcticamente todos los sistemas de videoconferencia. Durante el proceso de
codificacin basada en DCT una imagen se divide en bloques de 8 8 pixels que sern la entrada
de la DCT, en la que se reducen las redundancias. Seguidamente se realiza la cuantificacin utili-
zando funciones con peso optimizadas para el sistema visual del ojo humano. Como la visin
humana es menos sensible al color que al brillo, la gradacin de niveles en la cuantificacin de
los valores de color pueden ser mayores que la de los valores de intensidad, es decir, la distancia
entre los niveles de los valores cuantificados puede ser mayor. Esto permite un mayor grado de
compresin para los componentes de color sin provocar una degradacin perceptible de la ima-
gen. Anlogamente, como la visin humana es menos sensible a los detalles de alta frecuencia
(variaciones rpidas) que a los de baja frecuencia (variaciones lentas), la cuantificacin de los
valores de alta frecuencia puede ser mayor, obtenindose una compresin extra sin deteriorar sig-
nificativamente la calidad de la imagen.
Como se comprime a lo largo de todo el rango de datos la operacin de cuantificacin sobre la
matriz de frecuencias resultante de la DCT se convertir en una matriz alterada que contiene
muchos valores iguales debido a la cuantificacin. En particular una matriz cuantificada contiene
muchos ms ceros. La matriz cuantificada puede tratarse de manera inversa para recuperar de
forma aproximada la original, pero siempre habr prdidas de mayor o menor importancia en
funcin del tamao de la granularidad de la cuantificacin.
Finalmente los datos resultantes de la cuantificacin se codifican en entropa utilizando un
esquema de Huffman de longitud variable. Para descomprimir la imagen se realiza el proceso
inverso. El esquema general de la compresin con DCT directa se ilustra en la figura 10.3.
Figura 10.3 Esquema general de la codificacin con DCT directa.
Estas tcnicas de compresin se aplican sobre un nico bloque de datos, por lo que se denominan
intrabloques. En ningn caso consideran los datos que no estn en el bloque tratado. En general
con estas tcnicas de compresin pueden obtenerse razones de compresin de 20 a 1 o 30 a 1.
En la codificacin vectorial los cambios en la posicin de un pxel se representan mediante
nmeros que indican la magnitud y la direccin. La VQ elimina menos informacin sobre los
datos de color que la DCT, pero tiende a difuminar movimiento en los laterales de una imagen
que se mueve rpidamente. Con VQ una palabra digital transmitida representa los valores cuanti-
ficados de ms de una muestras de la seal. Para imgenes, un nico vector normalmente repre-
senta un array de 4 4 pixels. VQ es un algoritmo altamente asimtrico. La codificacin necesita
un proceso complejo de bsqueda para determinar qu vector se transmite y la decodificacin
consiste meramente en utilizar una tabla de consulta para dibujar el valor correspondiente.
Las tecnologas con fractales y wavelets se basan en tcnicas avanzadas en el procesamiento de
seales digitales. Las wavelets descomponen una imagen en componentes frecuenciales
mediante un filtrado iterativo paso baja y paso alta que se realiza sobre la imagen completa, no en
DCT
hacia delante
Cuantifucador
Codificador de
Entropa
Datos de la imagen
comprimida
Tabla de
especificaciones
Tabla de
especificaciones
Datos de imagen
original
bloques 8x8
bloques. El resultado es una representacin jerrquica de la imagen en la que cada capa repre-
senta una banda de frecuencia.
La compresin fractal es lenta debido a su complejidad, pero produce una tamao de fichero
mucho menor que con otras tcnicas, y la descompresin puede realizarse con software. La
empresa Iterated Systems, Inc ha apostado fuerte por la tecnologa fractal y desarrolla tecnologa
para la compresin de imgenes de calidad desde CD-ROM. Esta empresa tambin es muy activa
en la distribucin de vdeo a travs de Internet y est desarrollando tecnologa para videoconfe-
rencias bidireccionales.
Por otro lado Aware Inc., promociona las wavelets como una forma de mejorar la calidad de la
compresin de vdeo, y tiene licenciada la mayora de su tecnologa a Analog Devices, que es
tambin lder en el campo de las wavelets. Al contrario que la DCT, la DWT, se aplica sobre la
imagen completa, eliminando con ello los efectos debidos a la particin en bloques, tpicos de las
tecnologas basadas en DCT.
Adems de la clasificacin de la compresin de video en cuatro tipos que se acaba de describir,
suele establecerse que existen dos tipos de aproximaciones al problema de la compresin de
vdeo, de acuerdo con el hecho de que se base en datos de un nico frame o no. Si la tcnica se
basa en los datos de un nico frame se conocen como intraframes. Un ejemplo tpico de estndar
basado en intraframes es el JPEG. Mientras que si se obtiene compresin adicional mediante la
comparacin de varios frames se denomina interframe. Las tcnicas interframe aprovechan las
similitudes (redundancia) que existe entre frames adyacentes.
Si se quieren conseguir razones de compresin mayores manteniendo una calidad aceptable la
mayora de los dispositivos de compresin utilizan tcnicas interbloques, que utilizan informa-
cin de otros bloques realizando comparaciones bloque a bloque. Una aproximacin interbloques
sencilla consiste en calcular la diferencia entre dos bloques adyacentes y comprimir y transmitir
slo la diferencia. Por ejemplo puede restarse el bloque 15 del 16 y comprimir la diferencia, ya
que no es de esperar que las diferencias sean muy grandes entre los datos de un bloque y el
siguiente. De hecho se espera que haya un gran numero de ceros tras la resta, y los ceros son fci-
les de comprimir. Por tanto, si se realizan comparaciones bloque a bloque hay un gran nmero de
tcnicas de estimacin y de compensacin de movimiento que permiten deducir cmo se ha
podido mover el frame, por ejemplo desplazado cuatro pixels a la derecha y hacia arriba tres. En
consecuencia, se est enviando al receptor por el canal de comunicacin cmo desplazar la ima-
gen anterior. Como puede imaginarse estas tcnicas se caracterizan por una gran capacidad de
compresin, es decir, razones de compresin mucho mayores. El coste de esta mejora se encuen-
tra en el hecho de que los algoritmos son mucho ms complejos y necesitan ms recursos de cl-
culo.
La figura 10.4 muestra que con compresin intrabloques se eliminan redundancias con un nico
frame, mientras que la compresin interframe elimina redundancias entre frames adyacentes.
Figura 10.4 Compresin intraframe e interframe.
Mapa de
bits
RGB
Traduccin
al espacio de colo
YUV
Azul
Verde
Rojo
Luminancia
Crominancia
Tranformada
al dominio de
la frecuencia
Cuantizacin
Codificacin
Run lenght
Codificacin
Huffman
Compresin intraframe
Frame actual
Frame anterior
Compresin interframe
Cambios
Las diferencias representan
el frame completo
Dispositivos de comparacin
Hoy en da existen soluciones que permiten codificar y descodificar mediante software y hard-
ware en diversas combinaciones: codificacin y descodificacin hardware, ambas software o una
hardware y la otra software. Adems 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 relacin entre calidad y nmero de bits por pxel con las tcnicas
de compensacin de movimiento. Como puede observarse con una tcnica determinada, para
mejorar la calidad de imagen tiene que aumentarse el nmero de bits por pxel. Pero se puede
aumentar la calidad de la imagen con un nmero fijo de bits por pxel si se utilizan tcnicas de
compresin interbloques cada vez ms y ms complejas.
Figura 10.5 Relacin entre calidad y nmero de bits por pxel con las tcnicas de compensacin de movimiento.
10.4 ESTNDARES DE COMPRESIN DE VIDEO
Los estndares de compresin de vdeo proporcionan un gran nmero de ventajas, siendo la ms
importante el hecho de que facilitan la interoperabilidad. Asegurar la interoperabilidad permite
que 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 comunicacin entre dispositivos diseados
por diferentes fabricantes. Los estndares permiten una aceptacin ms rpida de los productos
as como un uso ms amplio. Adems se disean para un gran nmero de aplicaciones, por lo que
se reducen costes debido a la economa de escala.
Actualmente existen dos familias de estndares de compresin de vdeo, 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 Telephone
Consultative Committee, o CCITT, y en segundo lugar la ISO, International Standards Organiza-
tion.
Algoritmo de futuro movimiento
compensado
Compresin de movimiento
compensado
Compresin de imagen
esttica
Nmero de bits/pxel
Calidad de
la imagen
El primer estndar de compresin de vdeo que consigui una muy amplia aceptacin fue el ITU
H.261, que fue diseado para la transmisin de videoconferencia sobre la red de servicios digita-
les integrados, RDSI. El H.261 fue adoptado como estndar en 1990, y fue diseado para funcio-
nar a velocidades con mltiplos p=1, 2,..., 30 de la velocidad de datos de la lnea base RDSI, es
decir, a p 64 kb por segundo.
En 1993, la ITU-T inici un esfuerzo de estandarizacin en la que el primer objetivo era la telefo-
na con vdeo sobre la red pblica de telefona conmutada, PSTN en USA (Public Switched Tele-
phone Network), RTB en Espaa (Red Telefnica Bsica). Estas redes son lneas telefnicas
analgicas convencionales, en las que la capacidad total en la velocidad de datos es slo de 33.6
kb por segundo. La parte del estndar referente a la compresin de vdeo se denomina H.263, y
su primera fase fue adoptada en 1996. Una versin H.263 realzada, conocida como H.263+, fina-
liz en 1997. En la actualidad se est desarrollando un nuevo estndar de compresin conocido
como H.26L.
Existen numerosos estndares para los Codecs publicados por la ITU-T, y adems de los comen-
tados cabe destacar las tcnicas de compresin H.261 para video y la G.728 para audio.
El grupo de expertos conocido como MPEG, (Moving Pictures Expert Group), fue establecido
por la ISO en 1988 con el fin de establecer un estndar para la compresin de imgenes en movi-
miento y el audio asociado a medios de almacenamiento digitales tales como CD-ROM. Es
estndar que result inicialmente, conocido como MPEG-1, finaliz en 1991. Este proporciona
aproximadamente calidad de vdeo VHS y audio con alrededor de 1.5 Mb por segundo. La
segunda fase de su trabajo desarroll el siguiente compresor, denominado MPEG-2, que era una
extensin del MPEG-1 desarrollada para la emisin de televisin digital y con velocidades de bit
mayores.
Actualmente la mayora de los estndares de televisin digital, DTV, y de televisin digital de
alta definicin, HDTV, se basan en la tecnologa MPEG-2 tanto en Norte Amrica y Europa
como en Asia.
Recientemente ha finalizado la tercera fase del trabajo de este grupo de estandarizacin, desarro-
llando el estndar conocido como MPEG-4. El objetivo fundamental del MPEG-4 es proporcio-
nar una funcionalidad creciente, incluyendo procesamiento basado en contenido, integracin
tanto natural como sinttica, material generado por computador e interactividad con la escena.
La tabla 10.1 muestra los estndares de compresin ms habituales con sus aplicaciones caracte-
rsticas y la velocidad de bits que son capaces de desarrollarse con cada tecnologa.
El bitrate, tasa de bits o velocidad de bits especifica nicamente el nmero de bits por segundo
que tiene una secuencia. Si disminuye a valores muy pequeos, se tienen muy pocos bits por
frame. Esto hace que al reproducir el video sea evidente esa prdida de informacin y se obtenga
una imagen degradada. As pues ajustando la velocidad de bits se determina cuntos bits por
segundo se utilizan para almacenar la informacin. Esto a su vez determina la perdida de infor-
macin y con ello la calidad de la imagen.
Tabla 10.1 Estndares de compresin ms habituales con sus aplicaciones caractersticas y la velocidad de bit.
Los fabricantes que utilizan los Codecs basados en estndar son probablemente los que disfrutan
de mejor interoperatividad. Sin embargo, los algoritmos de propietario pueden ofrecer ventajas
en determinadas situaciones. Si la necesidad de interoperatividad o de soportar contenidos de
otros fabricantes es mnima entonces tiene el sentido para el diseador utilizar un algoritmo de
compresin de propietario. Algunos algoritmos son estndares de hecho debido a su amplia utili-
zacin por los usuarios y por estar disponibles a muy bajo coste, y sin embargo nunca han sido
estandarizados oficialmente.
Una cuestin muy importante es qu especifica realmente un estndar de compresin de vdeo.
Esto permitir adems de conocer cul es su aplicacin fundamental, de qu manera es compati-
ble con otros sistemas u otras tecnologas desarrolladas para la misma o diferente aplicacin. En
general, un sistema de compresin de vdeo est formado por un codificador, secuencias de bits
comprimidas y un decodificador. El codificador recibe la seal de vdeo original y la comprime
en una secuencia de bits. Est secuencia entrar en el decodificador que realizar el proceso
inverso para reconstruir el vdeo original. La figura 10.6 muestra este esquema bsico.
Figura 10.6 Esquema bsico de una especificacin del estndar.
Una posibilidad para definir un estndar es que este especifique tanto el codificador como el
decodificador, pero esta aproximacin tendra un gran nmero de desventajas, todas ellas relacio-
nadas con el hecho de que el detalle de estos elementos provocara que cualquier pequea modi-
ficacin no fuera compatible, incluso cuando se pudieran conseguir los mismos resultados. En
lugar de ello, los estndares delimitan las caractersticas que especifican con el fin de asegurar la
ESTANDARD APLICACION BIT RATE
JPEG Compresin de imgenes tonos continuos Variable
H.261
Telefona de vdeo y teleconferencia sobre
RDSI
p x 64 kb/s
p=1, 2,,30
MPEG-1
Vdeo sobre medios de almacenamiento
digital (CD-ROM)
1.5 Mb/s
MPEG-2 Televisin Digital. DVD > 2 Mb/s
H.263 Telefona de vdeo sobre RTB < 33.6 kb/s
MPEG-4
Codificacin basada en objetos, contenido
sinttico, interactividad
Variable

Vdeo
Original
Codificador Decodificador
Bits-stream
Secuencia de bits
Video
Reconstruido
interoperabilidad a la vez que permiten que en las implementaciones concretas haya diferencias
en la medida de lo posible.
En concreto, los estndares no especifican ni el codificador ni el decodificador, tal y como ilustra
la figura 10.7. En lugar de ello especifican la sintaxis de la secuencia de bits y el proceso de
decodificacin. La sintaxis de la secuencia de bits es el formato en el que se representan los datos
comprimidos. El proceso de decodificacin es el conjunto de reglas o tcnicas que permiten
interpretar la secuencia de datos.
Figura 10.7 Especificaciones de los estndares.
Aparentemente este hecho es igual a especificar el decodificador, pero no es as. Obsrvese que
el especificar el proceso de decodificacin es diferente a especificar una implementacin particu-
lar de un decodificador. Por ejemplo, el estndar puede especificar que el decodificador utiliza
una 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 o
mediante una transformada rpida de Fourier, FFT, o utilizando instrucciones MMX. En este
caso, la eleccin de la implementacin tendr como consecuencia un mayor o menor coste com-
putacional lo que repercutir en un mayor o menor tiempo para realizar la descodificacin, o una
mayor o menor precisin en el clculo, pero no afecta al estndar. La especificacin de la imple-
mentacin no estara estandarizada. Esto permite a los diferentes diseadores y fabricantes desa-
rrollar sus tecnologas de manera diferente dentro del mismo estndar.
El proceso de codificacin tampoco se estandariza. Por ejemplo, pueden disearse los codifica-
dores ms sofisticados para proporcionar mejoras significativas en las especificaciones de los
codificadores bsicos.
Adems, un aspecto fundamental que resulta una extraordinaria ventaja debida a que no se espe-
cifica en la estandarizacin ni el codificador ni el decodificador es que pueden incorporarse las
mejoras que se van desarrollando sobre los algoritmos, incluso cuando el proceso de estandariza-
cin ha finalizado y el estndar est completamente definido. Por ejemplo, las mejoras realiza-
das en los algoritmos y en las tcnicas de estimacin o compensacin de movimiento o para la
localizacin de bits pueden irse incorporando y se podrn incorporar en el futuro de forma com-
patible con los estndar ya establecidos. La nica limitacin es que el codificador produzca una
secuencia de bits sintcticamente correcta de manera que pueda ser descodificada de forma apro-
Proceso de decodificacin
mbito de la estandarizacin
piada por cualquier decodificador compatible con el estndar. En conclusin, es importante
recordar que no todos los codificadores y decodificadores de un estndar determinado son igua-
les.
A continuacin se describirn las tcnicas ms significativas de la compresin de vdeo. Pero en
general la compresin se obtiene explotando las similitudes o correlaciones que existen en un
seal de vdeo tpica. Esto puede entenderse como una reduccin de la redundancia que se da en
los datos de vdeo. Existen tres clases de redundancia bsicas:
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 una
secuencia de vdeo estn altamente correlacionados, ya que en general contienen los mismos
objetos. Es probable que de un frame al siguiente lo que se ha producido es algn tipo de movi-
miento, un desplazamiento haca 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 de
los pixels cercanos estn a menudo correlacionadas.
Por ltimo la redundancia espacial de color hace referencia al hecho de que a menudo estn
correlacionadas 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-
sin.
La segunda caracterstica en la que se basa la compresin de vdeo es la irrelevancia en la seal
de vdeo, fenmeno que consiste en reducir la informacin que no es perceptualmente impor-
tante, o que de hecho no ser percibida por los aparatos sensoriales humanos. Desgraciadamente
la percepcin visual humana es muy difcil de modelar, por lo que determinar qu datos son pre-
ceptualmente irrelevantes es una tarea difcil, por lo que la irrelevancia es difcil de explotar. De
hecho slo los algoritmos ms avanzados y los estndares de mayores prestaciones hacen uso de
esta caracterstica.
Antes de analizar las tcnicas bsicas de compresin de vdeo es recomendable recordar breve-
mente cmo se comprimen las imgenes. Para ello se analiza cmo funciona el estndar JPEG.
Estndar JPEG (imgenes)
JPEG es una sencilla tcnica de compresin intrabloque y se utiliza para las imgenes estticas,
como por ejemplo fotografas. Si se dispone de potencia de clculo suficiente para realizar el
algoritmo JPEG 25 veces por segundo, entonces a menudo se denomina JPEG motion (MJPEG).
Como se acaba de comentar una imagen, o un frame de vdeo, contiene a menudo redundancia
espacial significativa ya que los bits cercanos son frecuentemente muy similares. Las imgenes
en la naturaleza son normalmente de contenidos paso baja (de variacin suave), y los algoritmos
de compresin de imgenes, como el JPEG, basan sus tcnicas de compresin en la redundancia
espacial y la naturaleza paso baja de las imgenes tpicas.
En el estndar JPEG la imagen se divide en primer lugar en bloques de 8 8 pixels. Seguidamente
para cada bloque se calcula la transformada discreta del coseno, DCT. La razn para dividir una
imagen en bloques pequeos es que en general los pixels de un bloque pequeo sern ms simila-
res que los que estn en un bloque grande.
La transformada DCT compacta la mayora de la energa de la seal de cada bloque en slo una
fraccin de coeficientes de la DCT. Entonces la cuantificacin de los coeficientes DCT conduce
a que la mayora de ellos sean cero. Los coeficientes cuantificados son seguidamente escaneados
en zigzag, codificados en longitud y esta codificacin con los valores de las amplitudes son codi-
ficadas con el cdigo de Huffman para convertirlos en una secuencia de bits comprimida.
En el caso de una imagen en color se aplica la conversin del espacio de color antes de calcular la
DCT. Esta conversin del espacio de color convierte la imagen RGB en un espacio de color
determinado por la luminancia y la cominancia, en el que pueden explotarse mejor la diferente
percepcin visual humana a las caractersticas de luminancia y cromarismo.
En resumen la compresin 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 cdigo de Huffman los coeficientes DCT cuantificados no nulos.
La figura 10.8 muestra el esquema bsico del estndar de compresin JPEG.
Figura 10.8 Esquema bsico del estndar de compresin JPEG de una imagen.
10.5 PRINCIPIOS BSICOS DE LA COMPRESIN DE VDEO.
Una secuencia de vdeo est formada por una secuencia de frames de vdeo o imgenes. Cada
frame puede codificarse como un paquete separado, por ejemplo aplicando independientemente a
cada frame una codificacin del tipo JPEG. Sin embargo, el vdeo tiene la caracterstica de que
los frames cercanos a un frame de vdeo son usualmente muy similares. La compresin de vdeo
puede obtener razones de compresin mucho mayores que la compresin de imgenes explo-
tando la redundancia temporal o las similitudes entre frames.
Imagen
Original
DCT
Bitsteam
Cuantizador Codificador
El hecho de que los frames cercanos entre s sean habitualmente muy similares puede explotarse
codificando un frame determinado predicindolo en primer lugar, tomando como base un frame
codificado previamente y posteriormente codificando el error de prediccin.
Los tres tipos bsicos de codificacin 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 bsicos de codificacin de frames.
Figura 10.9 Los tres tipos bsicos de codificacin de frames: I-frame, P-frame y B-frame.
Las tcnicas de prediccin de la compensacin de movimiento, P-frames y B-frames, se funda-
mentan en las mismas ideas bsicas, aunque posiblemente en diferentes localizaciones espacia-
les. Para aprovechar la capacidad de prediccin entre frames cercanos y vecinos es importante
estimar el movimiento entre dos frames y posteriormente construir una prediccin apropiada que
compense el movimiento producido.
El proceso de estimacin del movimiento entre frames se conoce como estimacin del movi-
miento. El proceso de prediccin de un frame determinado se basa en un frame de referencia
codificado anteriormente, mientras que la compensacin para los movimientos relativos entre
dos frames se conoce como prediccin de movimiento compensado.
Figura 10.10 Ejemplos de prediccin de movimiento compensado. a) hacia delante, P-frames b) bidireccional, B-frames.
Frame Anterior Frame Siguiente
La prediccin de movimiento compensado basada en bloques se utiliza frecuentemente debido a
que proporciona buenas especificaciones y tiene una estructura bsica peridica que simplifica
las implementaciones.
La figura 10.10 muestra ejemplos de prediccin de movimiento compensado hacia delante en la
figura 10.10.a y bidireccional en la figura 10.10.b.
El frame tratado para ser codificado se divide en bloques de 1616 pixels.
Para cada bloque en el frame a tratar se construye una prediccin, y se busca el bloque que mejor
se acopla, el ms 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 conocido
como vector de movimiento. La arquitectura bsica de la compresin de vdeo es la siguiente.
Los estndares de compresin de vdeo actuales obtienen la compresin aplicando los mismos
principios bsicos. La redundancia temporal se explota aplicando la prediccin MC (Motion
Compensation) mientras que la redundancia espacial se explota aplicando la DCT. La redundan-
cia espacial de color se explota mediante la conversin del espacio de color. Los coeficientes de
la transformada DCT se cuantifican y los coeficientes cuantificados no nulos se codifican
mediante el cdigo de Huffman para producir la secuencia de bits comprimida.
Figura 10.11 Esquema genrico de alto nivel de un codificador de vdeo.
RGB
a
YUV
DCT Cuantizador
Codificacin
Huffman
+
-
Buffer
Seal de
Vdeo de
Entrada
Residuo
Bitstream
de salida
Cuantizador
inverso
DCT
inversa
Datos MV
Compensacin
de movimiento
Estimacin
de
movimiento
Datos MV
Prediccin
Frame Previo
Reconstruido
El esquema genrico de alto nivel de un codificador de vdeo se ilustra en la figura 10.11. Como
se coment anteriormente los diversos estndares de vdeo especifican la sintaxis de la secuencia
de bits y el proceso de descodificacin, pero no especifica el proceso de codificacin ni la imple-
mentacin del codificador. Por ello debe tenerse en cuenta que los esquemas genricos slo
deben entenderse como ejemplos de codificadores o decodificadores tpicos de un sistema de
compresin de vdeo.
En el codificador la seal de entrada RGB se transforma en primer lugar en un espacio de color
determinado por la luminancia y el cromatismo, conocido como YUV, con el fin de explotar la
redundancia en el espacio de color.
Para explotar la redundancia temporal se utilizan la estimacin de movimiento y la prediccin de
la compensacin de movimiento, con el fin de construir una prediccin del frame que se est tra-
tando a partir de un frame previamente codificado.
El error de prediccin, o residuo, se divide en bloques de 88 pixels y se calcula la 2-D DCT para
cada bloque. Los coeficientes de la transformada DCT se cuantifican de forma adaptativa para
explotar las caractersticas locales del vdeo y las de la percepcin humana. Los coeficientes
cuantificados y otra informacin se codifican con el cdigo de Huffman para aumentar la eficien-
cia. A menudo se utiliza un bfer para acoplar al canal de comunicacin utilizado y la velocidad
de los bits de salida de vdeo del codificador, que es variable. Esto se consigue mediante un
mecanismo de control de almacenamiento en el que se controla la ocupacin del bfer en funcin
de los coeficientes de cuantificacin, regulando por tanto la velocidad de bits.
La figura 10.12 muestra el esquema genrico de alto nivel de un decodificador de vdeo
Figura 10.12 Esquema genrico de alto nivel de un decodificador de vdeo.
El proceso de decodificacin de vdeo es evidentemente el inverso al proceso de codificacin. La
secuencia de bits se analiza y se realiza la descodificacin de Huffman. Los coeficientes no nulos
de la transformada DCT se identifican y se realiza la cuantificacin inversa. Seguidamente se
realiza una transformada inversa DCT del bloque que produce la seal residual, que se combina
espacialmente de una forma adaptativa con el frame reconstruido previamente con el objetivo de
reconstruir el frame que se est tratando.
Decodificador
Huffman
Cuantizador
inverso
DCT
inversa
+
Buffer
Bitstream
de entrada
Compensacin de
movimeinto
Datos MV
DCT
inversa
Residuo
Prediccin
Seal de vdeo
de salida
Frame
reconstruido
Finalmente el frame reconstruido se reconvierte al espacio de color RGB para producir la seal
de salida de vdeo.
Los estndar de compresin de vdeo actuales se fundamentan en la misma construccin de blo-
ques bsica, que incluyen prediccin de movimiento compensado, DCT, cuantificacin escalar,
codificacin de Huffmann,... Las especificaciones adicionales que se incorporan para aplicacio-
nes particulares incluyen entre otras la capacidad de codificar vdeo entrelazado y herramientas
para flexibilizar los errores o para la escalabilidad.
La diferencia principal entre los estndares de compresin de vdeo radica en el hecho de que los
estndares iniciales, incluyendo H.261, H.263, MPEG-1, y MPEG-2, utilizaban codificacin
basada en frames. En concreto, estos estndares analizan cada frame como un grupo rectangular
de pixels y codifican estos pixels utilizando prediccin de compensacin de movimiento basada
en bloques y transformada DCT de bloque. Efectivamente, estos estndares modelaban el vdeo
como si estuviera compuesto de bloques rectangulares en movimiento. De forma contraria, el
estndar MPEG-4 proporciona la capacidad de modelar el vdeo como si estuviera compuesto
por un nmero de objetos separados, tales como personas, coches o fondos, y cada objeto puede
tener una forma arbitraria no cuadrada. El MPEG-4 utiliza los mismos bloques bsicos de cons-
truccin de la imagen, pero los aplica a objetos de formas arbitrarias.
Los estndares ms comnmente utilizados y sus caractersticas bsicas son los siguientes:
H.261, H.263, MPEG-1, MPEG-2. Basados en la codificacin de frame.
Basados en la misma construccin fundamental de los bloques.
Prediccin de la compensacin de movimiento e interpolacin.
Transformada 2-D DCT, Transformada del Coseno Discreta.
Conversin del espacio de color.
Cuantificacin escalar, run-length, y codificacin de Huffman.
Otras herramientas incorporadas para diferentes aplicaciones.
Vdeo progresivo o entrelazado.
Compresin mejorada, flexibilizacin de los errores, escalabilidad,...
MPEG-4. Codificacin basada en objetos y vdeo sinttico.
Se aplica a todo tipo de representacin de datos. Desde video (altas y bajas tasas
de bits) y msica 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 representacin 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 caractersticas ms sobresalientes de los diferentes
estndares de compresin de vdeo. En primer lugar se examinan los estndares MPEG-1 y
MPEG-2 ya que son los ms populares, posteriormente los H.261 y H.263 y finalmente se ana-
liza el estndar MPEG-4 que es el ms novedoso y en muchos aspectos el ms revolucionario.
MPEG-1 y MPEG-2
El grupo MPEG, Moving Pictures Expert Group, fue establecido originalmente por la ISO con el
fin de desarrollar un estndar para la compresin de imgenes en movimiento, video, y audio
asociado a medios de almacenamiento digital, tales como el CD-ROM. El estndar resultante,
conocido comnmente como MPEG-1, fue completamente definido en 1991 y proporciona cali-
dad de vdeo VHS aproximadamente, y audio de 1.5 Mbites por segundo.
Una segunda fase de su trabajo, conocida como MPEG-2, fue planeada inicialmente como una
extensin de MPEG-1, y fue desarrollada para aplicaciones que van desde el vdeo entrelazado
hasta la televisin 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 ms altas velocidades de bits, tal como la tele-
visin digital de alta definicin, HDTV, pero se comprendi que estas aplicaciones tambin
podran realizarse en el contexto del estndar MPEG-2. Por tanto, la tercera fase fue incorporada
en el estndar MPEG-2 y, como resultado, no existe el estndar MPEG-3.
Tanto el MPEG-1 como el MPEG-2 estn formados actualmente por diferentes partes que inclu-
yen vdeo, audio, sistemas, tests de conformidad, etc. La compresin de la parte de video de estos
estndares se conocen frecuentemente como MPEG-1 vdeo y MPEG-2 vdeo, o MPEG-1 y
MPEG-2 por brevedad.
En la actualidad el MPEG-2 vdeo ha sido adoptado como estndar para los contenidos de vdeo
de la televisin digital y la HDTV en la mayora de Norte Amrica, Europa y Asia. Tambin es la
base para el estndar de los discos de vdeo digital, DVD (Digital Versatile Video Disk).
El MPEG-2 es una versin avanzada del MPEG-1, capaz de soportar velocidades de bit ms
altas, mayor resolucin e imgenes entrelazadas para televisin. Para vdeo entrelazado los cam-
pos pares e impares pueden codificarse separadamente o pueden combinarse un par de campos
pares e impares y codificarse como un frame. Para la codificacin basada en campos, MPEG-2
ofrece mtodos basados en campos para la prediccin de compensacin de movimiento, DCT de
bloques y escaneado alternado en zigzag. Adems MPEG-2 ofrece un gran nmero de mejoras
incluyendo extensiones escalables.
En resumen, las caractersticas bsicas de estos estndares son las siguientes:
MPEG-1 (1991)
Objetivo: la compresin para medios de almacenamiento digitales, CD-ROM.
Obtiene calidad de vdeo aproximadamente VHS y audio a 1.5 Mbits/seg..
MPEG-2 (1993)
Superconjunto de MPEG-1 para soportar velocidades de bit ms altas, mayor reso-
lucin e imgenes entrelazadas para televisin.
Objetivo original: soportar vdeo entrelazado para televisin convencional. Even-
tualmente se extendi para soportar HDTV.
Ofrece codificacin basada en campos y herramientas de escalabilidad.
Seguidamente se describe la estructura bsica utilizada en los estndares MPEG. Los estndares
MPEG agrupan los frames de vdeo en unidades de codificacin denominadas grupos de imge-
nes, o GOPs. Los GOPs tienen la propiedad de que reinicializan la prediccin temporal utilizada
durante la codificacin, que es importante para habilitar el acceso aleatorio en una secuencia de
vdeo 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 vdeo, formado por los
frames desde I0 a B8, en los que el subndice indica el nmero de frame. El frame I9 ser el pri-
mero del siguiente GOP. Las flechas indican las dependencias de la prediccin. El frame en el
principio de cada flecha se utiliza para predecir el frame sealado por la flecha, el frame predi-
cho.
Figura 10.13 GOP con nueve frames de vdeo.
Los frames I se codifican independientemente de los otros frames. Los frames P dependen de la
prediccin basada en los frames I o P anteriores. Los frames B dependen de una prediccin
basada en los frames I o P tanto anteriores como posteriores. Obsrvese que cada frame B
depende de los datos de un frame futuro, lo que significa que el frame futuro debe descodificarse
antes de que el frame B que se est tratando pueda decodificarse.
Debe observarse que la utilizacin de los frames B aade un retardo adicional, al necesitar espe-
rar a la decodificacin de frames futuros. Por tanto los frames B son muy adecuados para la emi-
sin de contenidos o las aplicaciones con almacenamiento, pero muy a menudo no son
apropiados para las aplicaciones en tiempo real, comunicaciones bidireccionales o cualquier otra
aplicacin en la que la exigencia de mantener bajo el retardo sea importante.
El estndar MPEG codifica video en unidades jerrquicas denominadas secuencias de vdeo, gru-
pos de imgenes,imgenes, slices (rebanadas), macrobloques y bloques DCT. La prediccin de la
compensacin de movimiento se realiza sobre bloques de 1616 pixels. Un bloque de 1616
pixels se denomina macrobloque y se codifica utilizando DCTs de bloques de 88 pixels, tpica-
mente cuatro bloques de 88 pixels para la luminancia, dos bloques para la crominancia y posi-
blemente un vector de movimiento hacia delante y/o hacia atrs.
Los macrobloques se escanean desde la izquierda hacia la derecha y de arriba hacia abajo. Una
serie de macrobloques se denomina slice y todos los slices de un frame contienen una imagen.
Las imgenes contiguas forman un GOP, y todos los GOPs forman una secuencia completa. La
figura 10.14 muestra la estructura del estndar MPEG con la jerarqua de capas en las que se
codifica el vdeo.
Figura 10.14 Jerarqua de capas en las que se codifica el vdeo en el estndar MPEG.
Los estndares MPEG fueron diseados para emplearse en un gran nmero de aplicaciones
diversas en las que cada aplicacin necesita un nmero de herramientas diferentes o funcionali-
dades distintas.
Los codificadores y decodificadores que soportan todas las funcionalidades seran muy comple-
jos y caros. Sin embargo, una aplicacin tpica normalmente tiene suficientes herramientas con
un pequeo subconjunto de las funcionalidades MPEG. En consecuencia, con el fin de facilitar
las implementaciones ms eficientes para diferentes aplicaciones, MPEG agrup juntos diversos
subconjuntos 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 mximo o la complejidad
mxima de cualquiera de los parmetros de un perfil, tales como resolucin, velocidad de frame,
velocidad de bit, y tamao de bfer. La figura 10.15 muestra una versin simplificada de la
matriz bidimensional de los perfiles y niveles en MPEG-2 junto con una tabla de caractersticas..
Capa GOP Capa de imagen
Capa de divisin
Capa de bloque Capa de
macrobloque
Figura 10.15 Versin 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-
ficacin de perfil / nivel ms 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 la
compresin de televisin, en DVDs y en la definicin estndar de la trelevisin digital, conocida
como SD-DTV, (Standard Definition Digital Televisin). El segundo perfil muy utilizado es el
MP&HL, que se usa en la compresin de HDTV.
Una vez analizados los estndares bsicos de MPEG, seguidamente se describen los relacionados
con la ITU-T.
El estndar H.261
El estndar de compresin de vdeo H.261 se dise teniendo como objetivo las aplicaciones en
tiempo real y las comunicaciones bidireccionales. En estos entornos un requisito crtico es que el
retardo sea pequeo, por ello se especific que el retardo mximo permitido era de 150 milise-
PERFILES
Simple Principal 4:2:2 SNR Espacial Alto
Alto
4:2:0
19201152
80 MB/s

4:2:0 o 4:2:2
19201152
100 MB/s
Alto
1440

4:2:0
14401152
60 MB/s

4:2:0
14401152
60 MB/s
4:2:0 o 4:2:2
14401152
80 MB/s
Principal
4:2:0
720576
15 MB/s
Sin B
4:2:0
720576
15 MB/s
4:2:2
720608
50 MB/s
4:2:0
720576
15 MB/s

4:2:0 o 4:2:2
720576
20 MB/s
N
I
V
E
L
E
S

Bajo
4:2:0
352288
4 MB/s

4:2:0
352288
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 estndar RDSI se dise para funcionar sobre RDSI, a mltiplos p=1, 2,..., 30 de la
velocidad de la lnea base RDSI, es decir a p64 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 estimacin de movi-
miento y prediccin de la compensacin de movimiento en bloques de 1616 pixels y DCT por
bloques de 88 pixels. La estimacin de movimiento se calcula para obtener una precisin com-
pleta de pxel. El rango de bsqueda es de 15 pixels.
Una particularidad interesante es que el estndar H.261 ofrece la opcin de aplicar un filtro paso
baja dentro del lazo de realimentacin de la prediccin de compensacin del movimiento con el
fin de suavizar el frame previamente reconstruido como parte del proceso de prediccin. Este fil-
tro no se utiliza en los estndares MPEG-1 y MPEG-2, ni en el H.263 ya que utilizan estimacin
del movimiento con precisin de medio pxel y la interpolacin espacial resultante tiene un
efecto similar al del filtro. El estndar H.261 fue completado en 1990.
El estndar H.263
El estndar de compresin de vdeo H.263 fue estandarizado en 1995. Fue diseado centrando su
objetivo en las comunicaciones sobre lneas telefnicas analgicas convencionales. Transmitir
vdeo, habla y datos de control utilizando un mdem a 33.6 kb por segundo. Esto significa que
tpicamente slo se dispone de una capacidad de 20 a 24 kb por segundo para el contenido de
vdeo.
El codificador H.263 tiene una estructura similar al H.261. Fue diseado para facilitar la intero-
peratividad entre los codificadores de H.261 y H.263. Se introdujeron un gran nmero de mejo-
ras sobre el H.261, entre las que destacan las siguientes:
1.- Reduccin de la informacin requerida.
2.- Mejora de las especificaciones de la flexibilidad de los errores.
3.- Mejora en los algoritmos y en algunas de las tcnicas de codificacin para lnea base, inclu-
yendo estimacin de movimiento de medio pxel.
4.- Mejoras en la eficiencia de la compresin mediante cuatro opciones de codificacin avan-
zada. Son las siguientes:
- Modo de vector de movimiento no restringido.
- Modo de prediccin avanzada.
- Modo de codificacin aritmtica basada en sintaxis.
- Modo de frames PB.
Las opciones de codificacin avanzadas se negocian de manera que el codificador y el decodifi-
cador se comunican para determinar qu opciones pueden utilizarse antes de que comience la
compresin.
Cuando se utilizan todas las opciones de codificacin el estndar 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 estndar H.263 obtiene tpicamente una
mejora de aproximadamente 4 dB respecto al estndar H.261 a la misma velocidad de bits, o una
reduccin del 50% en la velocidad de bits para la misma calidad en la relacin seal-ruido, SNR.
El estndar H.263+ (Versin 2)
El estndar H.263+ es una extensin del H.263, es decir, se corresponde con el H.263 con algu-
nas especificaciones adicionales. Su nombre oficial es H.263, Versin 2. El H.263+ soporta un
rango de formatos de vdeo ms amplio, e incluye nuevas especificaciones para obtener caracte-
rsticas de la compresin mejoradas, mejorar la flexibilidad a los errores para la transmisin en
paquetes sobre redes. Tambin ofrece escalabilidad temporal. Espacial y SNR.
El estndar H.263+ fue completamente definido en 1997. En la actualidad se est finalizando la
estandarizacin de una nueva extensin, el H.263++, oficialmente el H.263 Versin 3.
Adems se est desarrollando un nuevo estndar de compresin, el H.26L, donde la L indica
grande (large). El H.26L ser un estndar completamente nuevo en el sentido de que no tiene
requisitos ni limitaciones de compatibilidad con los anteriores estndares H.263, y por tanto no
ser compatible.
El estndar MPEG-4
El estndar MPEG-4 es bastante diferente de sus predecesores, MPEG-1 y MPEG-2, ya que sus
principales objetivos se centran en permitir nuevas funcionalidades y no slo en proporcionar
mejoras en la compresin. El MPEG-4 soporta una representacin basada en objetos o basada en
contenidos. Esto facilita la codificacin separada de diferentes objetos de vdeo en una escena de
video. Adems permite el acceso individualizado y la manipulacin de diferentes objetos en un
vdeo. Obsrvese que el MPEG-4 no especifica cmo identificar o segmentar los objetos en un
vdeo. Esta operacin se realiza en el codificador que no est especificado en el estndar. Sin
embargo, si se conocen los objetos individuales, el MPEG-4 proporciona un mtodo para com-
primir estos objetos. El acceso y la manipulacin basada en contenidos es una de las caractersti-
cas fundamentales.
El MPEG-4 tambin soporta la compresin de objetos de vdeo sintticos o generados por com-
putador, as como la integracin de los objetos naturales y sintticos dentro de un nico vdeo.
Tambin facilita la interaccin con los objetos individuales del vdeo.
Adems soporta comunicaciones flexibles a los errores en canales como Internet y la tercera
generacin de sistemas sin cables, greles, resultando por tanto ms robusto. Tambin incluye la
mayora de las tcnicas de codificacin desarrolladas en los anteriores estndares. Como resul-
tado de ello, el MPEG-4 soporta codificacin de vdeo basada tanto en frames como en objetos.
La primera versin del MPEG-4 finaliz en 1999. Una segunda versin, conocida como MPEG-
4 Versin 2, fue estandarizada en 2000.
La figura 10.16 muestra un ejemplo de decodificacin MPEG-4 desarrollado en el comit de
estandarizacin del MPEG-4.
Figura 10.16 Ejemplo de decodificacin MPEG-4 desarrollado en el comit de estandarizacin del MPEG-4.
Como puede observarse el vdeo est formado por dos objetos naturales, la persona y la mesa, y
un objeto sinttico que es la presentacin. Tambin hay un objeto natural de audio.
Los distintos objetos se codifican independientemente. Con una descripcin de la escena, se mul-
tiplexa en una nica secuencia de bits y se enva por la red. El decodificador recibe la secuencia
de bits y demultiplexa los objetos codificados y la descripcin de la escena. Los objetos codifica-
dos individualmente se descodifican y la descripcin de la escena representan la manera en que
los diferentes objetos se componen y renderizan para formar el vdeo final que ser presentado.
La figura 10.16 muestra cmo los objetos naturales y sintticos pueden integrarse en la misma
escena.
Adems, la representacin basada en objetos facilita la manipulacin o la interaccin con los
objetos individuales en la escena. Por ejemplo, un objeto puede borrarse de la escena y otro
puede ser aadido.
Comparacin de los estndares MPEG-1/2 y H.261/3 con el MPEG-4
Existen varias diferencias importantes que resultan evidentes cuando se comparan los estndares
de compresin. MPEG-1, MPEG-2, H.261, y H.263 fueron diseados originariamente para com-
primir vdeo. Ofrecen mtodos para el almacenamiento o la transmisin de vdeo, utilizan mto-
dos de codificacin basados en frames y estn principalmente diseados para las
implementaciones hardware.
Por el contrario, el estndar MPEG-4 se dise como una gran conjunto de herramientas para una
gran variedad de aplicaciones. Estas herramientas soportan tanto codificacin basada en objetos
como basada en frames, y tambin soporta la codificacin de vdeo sinttico.
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 variedad
de aplicaciones, tales como interactuar con el vdeo 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 estndares MPEG
MPEG desarrolla dos estndares que se extienden ms all de la visin tradicional de la compre-
sin de vdeo y audio. Aunque estos estndares no se centran en la compresin, se mencionan
brevemente con el fin de clarificar su relacin con los otros estndar MPEG..
El objetivo del MPEG-7 es facilitar la bsqueda rpida y eficiente de contenidos multimedia, de
manera similar al modo en que lo realizan las herramientas o aplicaciones de bsqueda conven-
cionales en Internet, que facilitan las bsquedas rpidas de informacin textual.
En concreto el estndar de la descripcin del interfaz de los contenidos multimedia define un
conjunto de descriptores que pueden utilizarse para describir varios tipos de informacin multi-
media, tales como imgenes, vdeo, grficos, habla u audio, as como informacin sobre la crea-
cin y composicin de estos elementos.
Mientras que los anteriores estndares MPEG definieron nuevos estndares de compresin, el
objetivo del MPEG-7 es representar la informacin describiendo el contenido y no el contenido
en s mismo.
El MPEG-21 es una nueva estandarizacin. Su objetivo es facilitar el comercio electrnico de los
contenidos digitales. Se pretende que tenga una interoperatividad completa y transparente para
los contenidos que se manejen, disponiendo de forma conjunta la infraestructura de reparto, de
facturacin y de derechos. Es bastante diferente de los estndares MPEG basados en la compre-
sin. Sin embargo, incorporar los estndares de compresin, en particular el MPEG-2 y el
MPEG-4, para la compresin el suministro de contenidos.
Otros estndares: Propietarios
Como es de suponer los mtodos de compresin de propietario se caracterizan por pertenecer a
una empresa o un conjunto de ellas y suelen desarrollarse con objetivos particulares. Un ejemplo
de ellos son los mtodos para las Palm, que disponen de utilidades incompatibles entre productos
de distintos fabricantes. los usuarios de PocketPC lo tenan ms fcil y cmodo: puesto que
Microsoft siempre ha mantenido que los PPC son realmente multimedia, por lo que el Media Pla-
yer venia de serie. Eso permita ver algunos AVI.
DivX. Un codec de especial inters.
DivX, Digital Video Express, es un formato inicialmente pensado para aplicaciones DVD-ROM
promocionado por varias grandes compaas de Hollywood, entre las que destacan Disney, Drea-
mworks SKG, Paramount y Universal.
Originalmente se dise como sistema de proteccin a copias de DVDs y vdeo bajo demanda,
aunque no tuvo xito. Hoy en da es un compresor de vdeo basado en MPEG-4, con lo que
obtiene una mejor compresin respecto al MPEG-2 que se utiliza en los DVDs, en concreto alre-
dedor de un 10%, es decir, el tamao de la secuencia es un 10% menor. La compresin con res-
pecto a una cinta VHS est alrededor en un factor de 100. Adems utiliza MP3 para la
compresin de audio.
Las primeras compaas que lanzaron reproductores DVD capaces de soportar el formato DivX
fueron Kiss Technology en Europa y Liteon en USA. Lo hicieron utilizando chips Sigma Designs
EM8500 chipsets. La empresa Sigma Designs destac al ser la primera que fabric tarjetas PCI
para la compresin y descompresin mediante hardware. En diciembre de 2003 MediaTek lanz
la serie de chips MT1389 que estaban completamente garantizados por DivXNetworks (la
empresa oficial de DivX). Inmediatamente, en enero, ESS lanzlos chips Vibratto, que tambin
soportaban DivX. A partir de entonces se ha producido una explosin de reproductores DivX en
el mercado, con los chips MediaTek en la mayora 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 cdec AVI (Audio vides Interleaved, los AVI se analizan detalladamente a continua-
cin) que puede usarse tanto en capturas en tiempo real como en compresin en tiempo no real
gracias a la opcin de comprimir a doble pasada incorporada en la versin 4. La versin 5 est
disponible en tres versiones. La estndar incluye, principalmente opciones para reproducir vdeo
comprimido con DivX.
DivX no dispone de ninguna utilidad de compresin independiente o "stand alone", sino que se
instala como un codec AVI o Direct X disponible en el sistema. Es decir, solamente se puede
comprimir vdeo usando el codec DivX desde una aplicacin que trabaje vdeo AVI, como pue-
den ser Adobe Premiere, Ulead Media Studio, Xmpeg o Virtual Dub.
Aunque los vdeos resultantes son ".avi" en realidad DivX est basado en el cdec MPEG-4. Este
cdec fue diseado para la transmisin de vdeo mediante Internet, por lo que su cdigo est
especialmente optimizado para vdeos de muy baja velocidad de bit. Por tanto es ideal para
recomprimir una pelcula de 2 horas y almacenarla en un slo CD. Otra caracterstica importante
de DivX es que, al contrario que muchos otros codecs de compresin, admite entrada de vdeo en
formato YUV2, lo que acelera notablemente el proceso de compresin.
10.6 FORMATOS DE ARCHIVO DE VDEO.
El almacenamiento de contenidos de vdeo se realiza, como todos, en archivos, pero no es tarea
fcil. Como es lgico el vdeo no suele estar compuesto nicamente de una secuencia de imge-
nes, sino que suele estar formado por vdeo, sonido e incluso subttulos.
Adems, toda esa informacin 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 el
audio que se escucha.
Si se produce desincronizacin, sta puede ser de tres tipos:
El audio est desplazado en el tiempo con respecto al vdeo
El audio tiene distinto tiempo de duracin que el vdeo
El audio est desplazado en el tiempo y tienen distinta duracin que el vdeo
La ltima es una combinacin de las dos primeras, y la correccin de la desincronizacin va a ser
ms complicada, pudiendo llegar a ser imposible.
Desincronizacin 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 desincronizacin que tengamos. Este es un proceso iterativo, es decir, reprodu-
ciendo la pelcula se calcula cul es el valor de la desincronizacin existente, se realiza la
correccin y se verifica si se ha corregido la desincronizacin, en caso contrario, se vuelve a
empezar el proceso.
Para obtener una idea del valor de la desincronizacin existente, puede tomarse un pasaje de la
pelcula en dnde sea fcil realizar esto, por ejemplo en el disparo de un arma, el ruido de una
puerta al cerrarse o algo por el estilo, nunca deberemos fiarnos de las voces, ya que como estn
dobladas muchas veces el movimiento de los labios no coincide con el sonido.
Desincronizacin progresiva (distinto tiempo de duracin)
Si el vdeo y el audio tienen duracin distinta, cuando se reproduce la pelcula, a medida que va
avanzando sta, se va notando una desincronizacin progresiva, de forma que al final de la pel-
cula, la desincronizacin es mxima.
Desincronizacin con desplazamiento en el tiempo y distinta duracin.
Como ya se coment anteriormente, este caso es una combinacin de los dos anteriores, y es lo
peor que podra pasar. La solucin pasa por una mezcla de las dos anteriores, pero ambos efectos
hacen que sea sumamente complicada.
En general, las soluciones que funcionan bien para el audio no lo hacen para el video y a la
inversa. Por ello desde el principio se tuvo bastante claro que lo mejor era manejar cada cosa por
separado. Pero lgicamente, desde el punto de vista de los usuarios, es deseable tener un nico
fichero.
Este problema se ha resuelto con los formatos de distribucin. Se dise un formato de fichero
que actuase de contenedor de varios canales de informacin. Adems a esos formatos se les dot
de toda la informacin necesaria para sincronizar los diferentes canales. Esos formatos son los
que habitualmente conocemos como "formatos de video" entre los que se encuentran AVI, MOV
(Quicktime) y WMF (Windows Media file). Con ello, saber que una pelcula es un AVI, lo nico
que indica es cmo est organizada la informacin dentro del fichero, no cmo es esa informa-
cin.
Por ejemplo si queremos guardar video de 320x160 pixeles a 24 frames por segundo con 16 bits
de color se necesitan 320x160x16x24 = 19660800 bits por segundo = 18.75 Mbits por segundo,
que es una cantidad muy importante de informacin, pues implica 140 Mbytes por minuto. Es
decir en un CD se podran almacenar 4.55 minutos de video (y obsrvese que la resolucin es
muy baja). Evidentemente es necesario comprimir la informacin. Con lo que el segundo paso a
considerar es el mtodo de compresin de video que se ha utilizado. Dependiendo de cul se
haya utilizado, se dice por ejemplo que un AVI es DivX o Cinepak. Realmente lo que se debera
decir es que este AVI contiene un canal de video codificado mediante DivX o Cinepak. En el
mundo Apple, el formato es el MOV, tambin llamado QuickTime, y el codec habitual es el
QuickTime, que realmente es una implementacin de MPEG4, igual que el DivX. No deben con-
fundirse el continente y el contenido pese a que por economa de lenguaje aparentemente sean lo
mismo.
Lo mismo ocurre con el audio. Tambin se comprime para reducir su tamao y se hace con un
codec diferente al video y especfico para el audio. Por eso, dentro de un AVI se puede tener
video DivX y el audio codificado como un MP3 o como un OGG, PCM o WMA
Es inmediato comprender que los formatos de fichero estn ntimamente relacionados con los
mtodos de compresin, ya que la informacin que tendrn que contener los archivos depender
de cmo sea la compresin. Por ello es lgico que para cada estndar de compresin se determine
un tipo de archivo.
Seguidamente se describen los ms destacados y sus caractersticas fundamentales.
10.6.1 AVI: AUDIO VIDEO INTERLEAVED
Audio video Intercalado. Fue definido por Microsoft en 1992 y es uno de los ms comnmente
utilizado en la actualidad. Es un formato de fichero de video que permite la reproduccin del
vdeo mediante herramientas nicamente software, y es el estndar para la arquitectura multime-
dia VFW (Video For Windows).
Las cmaras de vdeo digitales ms comunes crean AVI cuando se importan las secuencias DV
desde la cmara. Estos archivos se suelen denominar DV-AVI porque la informacin de vdeo
incluida 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 vdeo
le sigue uno de audio, por lo que produce una reproduccin suave. Puede manejar 16.7 millones
de colores, y aproximadamente 10 Megabytes de video por minuto. Soporta diferentes mtodos
de compresin.
El formato AVI es una caso especial de archivo RIFF (Resource Interchange File Format). Esta
es una especificacin diseada en 1991 para almacenar contenidos multimedia. Pueden almace-
narse datos desde objetos de C++ hasta vdeos completos, y pueden aadirse nuevos tipos de
datos.
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 un
nuevo tipo de datos.
La mayor limitacin de este formato es que en principio la zona de datos no puede exceder los
cuatro gigabytes, debido a que est definido para 32 bits.
Figura 10.17 Esquema del Chunk del archivo RIFF
La base de la especificacin RIFF es una estructura de datos conocida como chunk, seccin, que
contiene 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 especializacin, o forma, del RIFF.
'AVI ', por ejemplo.
2.- Una seccin (Chunk)
(4 byte de identificador) (4 byte de tamao de seccin) (datos)
3.- Una Lista
'LIST' (4 byte de tamao 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-
loga en ingls porque sern los nombres de los campos en el estndar.
El formato AVI es una especializacin o "forma" del RIFF. La figura 10.18 muestra la estructura
bsica de este formato de archivo.
Figura 10.18 Estructura bsica del formato de archivo AVI.
Cada lista 'rec ' contiene los datos de sonido y vdeo para un nico frame en el segmento de datos
de sonido y en el de vdeo.
Los datos de sonido son normalmente PCM de 8 o 16 bits, estreo o mono, muestreado a 11, 22,
o 44.1 KHz.
Los datos de vdeo 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 cdigo de cuatro caracteres, como 'IV31' o 'CVID', en la cabecera
de la secuencia, que identifica el compresor utilizado. Por ejemplo, 'CVID' es el identificador
para CinePak, un compresor pionero para video compacto. Para el Indeo Video Interactive (Indeo
4.1, basada en la compresin mediante algoritmos wavelet) es 'iv41', etc.
Por ltimo, y con el nico fin de presentar el tipo de informacin que se detalla en el archivo,
seguidamente se detallan los contenidos de las cabeceras bsicas.
En chunk de encabezado AVI, contiene la siguiente informacin:
Total Frames: Nmero total de Frames (por ejemplo, 1500 frames en un AVI)
Streams: secciones (por ejemplo, 2 para audio y vdeo 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: Nmero mximo de bytes
BufferSize: Tamao del bfer.
Microseconds per Frame: microsegundos por frame
Frames per second: frames por segundo (por ejemplo, 15 fps)
Size: tamao (por ejemplo, 320x240 pixels)
Flags: Indicadores.
El chunk o encabezado de secuencia o seccin contiene la siguiente informacin:
Stream Type: tipo de stream (por ejemplo, 'vids' para vdeo y 'auds' para audio).
Stream Handler: controlador (por ejemplo, 'cvid' para CinePak)
Samples Per Second: muestras por segundo (por ejemplo, 15 frames/segundo para vdeo)
Priority: indica la prioridad
InitialFrames: Frames iniciales
Start: principio
Length: longitud en nmero de frames (por ejemplo, 1500 frames para vdeo)
Length (sec): longitud en segundos (por ejemplo, 100 segundos para vdeo)
Flags: Indicadores
BufferSize: Tamao del bfer.
Quality: calidad
SampleSize: Tamao de la muestra o frame.
Para vdeo, el chunk Formato del Stream contiene la siguiente informacin:
Size: Tamao (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 compresin utilizada (por ejemplo, 'cvid' para CinePak)
Para audio, el chunk Formato del Stream contiene la siguiente informacin:
wFormatTag: indica tipo de formato de audio (por ejemplo, WAVE_FORMAT_PCM)
Number of Channels: nmero de canales (por ejemplo, 2 para sonido estreo)
Samples per Second: muestras por segundo (por ejemplo 11025 muestras por segundo)
Average Bytes Per Second: Nmero medio de bytes por segundo (por ejemplo, 11025 para
sonido de 8 bits.
NblockAlign: nmero de alineamiento de bloque
Bits Per Sample: nmero de bits utilizados para cada muestra (por ejemplo 8 16 bits)
Tambin se pueden encontrar otros chunks que no forman parte del estndar, como puede ser el
siguiente:
'LIST' (4 bytes para tamao de la lista) 'INFO'
Permite almacenar informacin para ayudar a identificar el contenido de un chunk.
Los datos de audio son tpicamente PCM de 8 16 bits, stereo o mono, muestreados a 11, 22
44.1 kHz. Tradicionalmente se ha venido utilizando para la digitalizacin del sonido el Windows
PCM. Sin embargo, debido a su importante uso en Internet y las limitaciones de ancho de banda
existentes en la red, se ha incrementado el uso de codificadores de audio. Es por ello que el
campo wFormatTag en el chunk de audio identifica el formato de audio y el codificador.
10.6.2 MPEG: MOTION PICTURE EXPERT GROUP
Fue 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. Se
utiliza tanto para audio como para vdeo, texto, y grficos, mediante una nica secuencia de datos
sincronizada.
Las extensiones de los archivos con este formato son .mpeg, .MP1, .MP2, MP3 y MP4. La tecno-
loga que utiliza incluye patentes muy diversas de compaas e individuos de diferentes partes
del mundo ya que el comit MPEG slo estableces el estndar tcnico. El grupo de derechos de
propiedad intelectual MPEG-IPR (intellectual property rights) se constituy oficialmente en
Paris en marzo de 1994 con ms de 50 compaas entre fabricantes y usuarios de la tecnologa de
compresin 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 imagen
es bitmap y soporta imgenes mltiples. La tecnologa de compresin se basa en los estndares
MPEG.
La resolucin de la secuencia de vdeo fue en principio relativamente baja, posiblemente diez
veces menos que la original, pero tena una alta calidad de audio para CD.
En realidad no se ha definido concretamente un formato de archivo genrico para todos los
MPEG. Todo lo que se requiere para reproducir los datos MPEG es incluido directamente en la
secuencia de datos. Por tanto no son necesarias cabeceras ni cualquier otro tipo de campo de
informacin. Sin embargo, es posible que algn organismo internacional como MPEG o el DSM
(Digital Storage Medium), subgrupo de MPEG, lo haga en algn momento.
Normalmente los formatos de archivo se describen en trminos de offsets, (desplazamientos),
pero esto no es posible en MPEG porque resulta muy complicado por diversas razones. En pri-
mer lugar los campos de informacin se cuentan en bits en lugar de bytes, en segundo lugar
debido a la existencia de muchos campos de informacin que depende de valores de campos
anteriores y por ltimo a que la mayora de la informacin se propociona con cdigos de longitud
variable. Por ejemplo, los coeficientes de la transformada DCT se codifican de acuerdo con la
tabla mostrada en la figura 10.2. En ella, el nivel indica el valor de la DCT y la secuencia de
ceros define cuntos son ceros antes de l. La tabla completa tiene 112 entradas. De esta manera,
el estndar MPEG ISO 11172 describe el formato de archivo mediante un lenguaje tipo C.
Tabla 10.2 Tabla de codificacin 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 brillo
es similar en bloques cercanos. Debido a la codificacin con longitud de palabra variable, las
diferencias pequeas se codifican con menos bits que las grandes.
En el pasado la mayora de los archivos MPEG respondan al estndar ISO/IEC 11172-2.pero
fueron apareciendo cada vez ms ficheros del estndar ISO/IEC 111hardware72-1, porque la
mayora del hardware produca ficheros de los layer I/II MPEG con contenidos de vdeo y audio.
La estructura de fichero se muestra en la figura 10.19.
cdigo (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 son
de vdeo o de audio. Una cadena del Layer I MPEG puede tener hasta 16 canales de vdeo y 32 de
audio. Si se concatenan el paquete de datos de un canal de vdeo byte a byte se obtendra un
archivo de vdeo MPEG que respondera al estndar ISO/IEC 11172-2.
A continuacin se describe la estructura bsica 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 compresin (compresin layer).
Cada tren elemental se compone de unidades de acceso (Access Units, AU), que son las repre-
sentaciones codificadas de las unidades de presentacin (Presentation Units, PU), es decir, las
imgenes 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 de
forma ordenada y ampliados con informacin diversa que permite al decodificador separarlos y
garantizar la sincronizacin de la imagen y el sonido en la reproduccin.
Estructura MPEG 1
En MPEG 1 la parte 1 de la norma ISO/IEC 11172 (MPEG-1), denominada sistema, define las
reglas para la constitucin de una "capa de sistema" (system layer) que agrupa el video, el audio
y los datos privados en un solo tren, as como las condiciones sobre los trenes elementales que
permitan asegurar esta combinacin.
Las cinco funciones bsicas de la capa de sistema que empaqueta la capa de compresin son las
siguientes:
Sincronizacin de los mltiples trenes elementales comprimidos en la reproduccin.
Combinacin de estos trenes mltiples en un solo tren de datos.
Inicializacin de las memorias intermedias (bufers) al comienzo de la reproduccin.
Gestin continua de estas memorias intermedias.
Por ultimo, identificacin del tiempo por marcadores (time stamps).
Un conjunto de codificacin MPEG-1 de sistema debe realizar la codificacin de los datos de
video y audio, despus el multiplexado de esta informacin y de los datos privados, aadiendo la
Cdigo de comienzo de pack Cabecera de pack packet (paquete) packet (paquete) packet (paquete) cdigo de fin
Cdigo de comienzo de packet Cabecera de packet datos del packet
informacin necesaria para su sincronizacin y otras relativas a los recursos necesarios para la
decodificacin del tren binario MPEG-1, tales como el tamao de las memorias intermedias
necesarias para la decodificacin de cada uno de los trenes elementales con un decodificador de
frecuencia 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 los
datos. 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 cdigo de inicio de 32 bits, donde los 8 ltimos bits
identifican el tipo (audio, video o datos privados) y el nmero del tren elemental al que el
paquete de datos pertenece. La cabecera indica la longitud del paquete y el tamao de la memoria
intermedia de entrada necesaria para su decodificacin por el STD. La tabla 10.3 muestra la
informacin en un PES.
Tabla 10.3 Informacin en un PES.
Tambin puede contener un marcador de decodificacin (Decoding Time Stamp, DTS) que indi-
que el momento de decodificacin de la primera unidad de acceso (AU) del paquete y/o un mar-
cador de presentacin (Presentation Time Stamp, PTS) que indique el instante donde la unidad de
presentacin correspondiente (PU) debe ser "presentada" (visualizada o sonorizada, segn pro-
ceda).
Cdigo de
comienzo
Stream ID PTS STD DATOS ...
Paquete PES
Cabecera de Paquete
Campo Definicin (comentario) N.de bits
start_code_prefix prefijo del cdigo de inicio (00 00 01 hex) 24
stream_id tipo (4 bits de mayor peso) y nm. (4 bits de menor peso) del PES 8
packet_length longitud del PES (nmero 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 tamao del buffer (en mltiplos de 128 o 1024 bytes) 13
PTS (opcional) marcador de presentacin (cdigo de 4 bits+33 bits+marcador de 3
bits)
40
DTS (opcional) marcador de decodificacin (misma estructura que PTS) 40
packet_data_byte datos (N=packet_length menos tamao de los 6 campos sig.) Nx8

Cuando por ejemplo una secuencia de video debe ser presentada en un orden de IBBP, estas son
transmitidas con anterioridad en un orden de IPBB. Por tanto deben usarse dos tipos de marcas
de tiempo. El decodificador de marca de tiempo DTS indica el tiempo cuando una imagen debe
ser codificada, mientras la presentacin de marcas de tiempo PTS indica cuando esta debe ser
presentada a la salida del decodificador.
Cuando una secuencia IPBB es recibida, las dos imgenes I y P deben ser decodificadas antes de
la primera imagen B. Como un decodificador slo puede decodificar una imagen al mismo
tiempo; se debe decodificar una imagen I primero y luego debe ser almacenada, para tambin
decodificar despus una imagen P, con las cuales se pueden crear las imgenes B esperadas.
La figura 10.21 ilustra este procedimiento Primero se recibe una imagen I con sus respectivas
marcas de tiempo DST y PTS, estas marcas de tiempo son separadas un periodo de imagen. Si la
codificacin es bidireccional, una imagen P debe seguir y esta tambin vendr con marcas de
tiempo DTS y PTS, pero la separacin entre las dos marcas de tiempo es de tres periodos de ima-
gen, para permitir la inclusin de la imagen B. De este modo una secuencia IPBB es recibida. I es
demorada un periodo de imagen, P es demorada tres periodos de imagen, las dos imgenes B no
son demoradas y la presentacin de la secuencia descodificada es IBBP. Claramente si la estruc-
tura de las GOPs es cambiada de tal forma que hayan mas imgenes B entre I y P las diferencias
entre DTS y PTS de las imgenes P ser muy grande.
En los paquetes de audio existen marcas de tiempo del tipo PTS, pero como los paquetes de audio
nunca son transmitidos fuera de secuencia, entonces no hay marcas de tiempo del tipo DTS.
Figura 10.21 Ejemplo de cmo se usan PTS/DTS para sincronizar una codificacin 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 tambin para sincronizar las funciones de decodificacin de audio y
video, envindose con relativa frecuencia (la norma especifica un intervalo mximo de 0.7
segundos).
Se codifican sobre 33 bits, que representan un tiempo absoluto expresado en ciclos de reloj de
referencia a 90 KHz.
Un paquete puede contener a continuacin un nmero variable de bytes de datos, en funcin de
las caractersticas del soporte de grabacin o de transmisin utilizado.
La norma prev tambin la posibilidad de aadir un tren elemental de ajuste (padding stream)
para obtener un flujo constante o alinearse sobre los sectores fsicos de un dispositivo de almace-
namiento, as como los bytes de relleno (stuffing bytes) en el interior de un paquete (mximo 16
por paquete).
Los paquetes se agrupan en packs, cuya cabecera (pack header) proporciona la informacin de
timing 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 comn a 90
KHz (System Time Clock, STC) que sirve de base de tiempos y de unidad de medida para los
campos DTS y PTS de los paquetes. La figura 10.22 muestra la formacin de un paquete como
conjunto 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 cdigo de inicio de 32
bits.
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 parmetros del sistema utilizados para
el transcurso de este tren (flujo mximo, identificacin de los trenes elementales de audio, video
y datos, tamao mnimo del buffer de entrada, etc.).
La cabecera de sistema opcionalmente puede ser respetada durante cualquier nuevo paquete en
curso 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 tambin por un cdigo 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 Definicin (comentario) N. de bits
pack_start_code cdigo 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
SCR [14...0] reloj de referencia del sistema (15 bits de menor peso) 15
mux_rate velocidad del multiplex MPEG (en mltiplos de 50 bytes/s) 22

Cabecera de
Paquete
(Pack header)
Paquete de
Cabecera del
sistema
(System header)
Paquete de
Cabecera del
sistema
(System header)
... Siguientes
Paquetes ...
(nmero variable)
ltimo
Paquete
Cdigo de
Final
(ISO 11172)
Paquete Nmero 1
Contenido:
Pack_Start_Code (32 bits)
System_Clock_Reference
Mux_Rate
Contenido:
Informacin del sistema,
nmero y tipo de los trenes
elementales, PID de los PES
Contenido:
PES de Audio,
PES de Vdeo
datos privados
Paquete Nmero 1
Tabla 10.5 Estructura de la cabecera del sistema MPEG-1
El nmero de trenes elementales que pueden componer un tren MPEG-1 se especifica del
siguiente modo:
video: 0 a 16
audio: 0 a 32
datos privados: 0 a 2
Campo Definicin (comentario) N.de bits
system_header_start_code
cdigo de inicio de cabecera de
sistema
32
header_length
longitud de cabecera (N. de bytes
que quedan por seguir)
16
rate_bound
velocidad mxima (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 relacin armnica entre
STC y F
muestreo
de audio
1
system_video_lock_flag
"1" indica relacin armnica 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
identificacin del primer PES
(naturaleza y nmero)
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
tamao mx. del buffer (mltiplo de
128 o 1024 bytes)
13
stream_ID2
identificacin del segundo PES
(naturaleza y nmero)
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
tamao mx. del buffer (mltiplo de
128 o 1024 bytes)
13
etc. para (n-2) otros PES
idem para todos los PES (mx. 16
video, 32 audio, 2 private)
(n-2)x24

El tren MPEG-1 termina con un cdigo final, tambin de 32 bits (00 00 01 B9 hex).
La figura 10.23 muestra de forma esquemtica el contenido de un tren MPEG-1 completo.
Estructura MPEG 2
Al igual que en MPEG-1, los trenes elementales (ES) estn organizados en paquetes para formar
los Packetized Elementary Streams (PES) de video, audio y datos privados.
Tambin 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 organizacin del multiplexado
MPEG-2, prev dos maneras diferentes de multiplexar estos PES para formar dos tipos de trenes,
dependiendo de la aplicacin a la cual est enfocada.
Tren de programa (Program Stream). El tren "programa" de MPEG-2 se crea a partir de uno o
varias PES que deben obligatoriamente compartir el mismo reloj de referencia.
Paquete Nmero 1
Start_code_prefix
Start_code_prefix
Start_code_prefix
Stream_id
Packet_length
Packet_length
PES-header
sub-fields
Stuffing
Un byte
PES_scrmbling_control (2 bits)
flags de PES- header
3 bytes de flags
subcampos dependientes
de flags
Campo Definicin N de bits
start_code_prefix cdigo de inicio (00 00 01 hex) 24
string_id Identificacin 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-
misin sea susceptible de introducir muy pocos errores (error free medium), como es el caso, por
ejemplo, de las aplicaciones multimedia en CD-ROM o disco duro. Aqu, estos paquetes pueden
ser relativamente largos (por ejemplo, 2.048 bytes) pero estn organizados de manera similar a
un tren "sistema" MPEG-1.
Tren de transporte (Transport stream). El tren transporte de MPEG-2 est principalmente desti-
nado al transporte de programas de televisin a larga distancia sobre soportes o en medios sus-
ceptibles de introducir un ndice de errores bastante elevado (error prone medium); la longitud de
los paquetes debe ser relativamente corta para permitir la introduccin de los dispositivos de
correccin de errores eficaces.
La longitud de los paquetes transporte de MPEG-2 ha sido fijada, por tanto, en 188 bytes, valor
reservado especialmente para las emisiones va satlite, cable o terrestres de la norma europea
DVB.
Este tipo de tren est destinado a combinar varios programas que no compartan forzosamente el
mismo 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 creacin de un tren de transporte MPEG-2.
Figura 10.25 Creacin de un tren Transport MPEG-2 a partir de los PES que lo componen
Para el estndar MPEG-2 se utilizan cadenas elementales empaquetadas PES (Paquetized Ele-
mentary Stream):Esta sintaxis fue definida por MPEG-2 para la divisin de las largas cadenas
elementales de audio o video producidas por un codificador. Cada PES contiene una cabecera,
CP
CP=Cabecera de PES
CT=Cabecera de paquetes de transporte
Datos=Datos elementales: Audio, Vdeo, etc...
CA=Campo de Adaptacin

CT Datos CP
Otros
paquetes
de
transporte
CP Datos CP CP CA Datos
Otros
paquetes
de
transporte
CP CT Datos CP
Otros
paquetes
de
transporte
CP ......
PT1 PT2 PT3 PT4 PT5 PT6 PT7
188 bytes
Tren de
paquetes
de
transporte
184 bytes 184 bytes < 184 bytes 184 bytes
Paquete PES1 ( > 184 bytes) Paquete PES2 ( = 184 bytes)
header, con los datos necesarios para la descodificacin. A partir de los PES se forman las cade-
nas de transporte y programa definidas anteriormente.
Formacin del paquete de transporte MPEG-2
Un paquete "transport" de 188 bytes se compone de una cabecera de paquete (packet header), de
4 bytes y de una "carga til" (payload) de 184 bytes como mximo, eventualmente precedida de
un campo de adaptacin (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 televisin transmitidos por el canal, as como cierto nmero de datos
auxiliares que permiten al codificador no perderse por el tren de transporte MPEG-2.
Figura 10.26 Constitucin 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 y
la 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 slo puede transportar
datos procedentes de un slo paquete PES, y que un paquete PES empieza obligatoriamente al
principio de un paquete de transporte y se termina obligatoriamente al final de un paquete de
transporte.
Debido a la longitud mucho ms pequea de los paquetes de transporte (184 bytes tiles) con res-
pecto a los paquetes PES (por ejemplo, 2048 bytes), estos ltimos debern ser divididos en trozos
de 184 bytes.
Datos
Campo de
Adaptacin
(AF)
X bytes 184-X 4
188 bytes
Sync i-sima
8 bits
Datos Contador de
continuidad
1 1 1 13 2 2 4
Transport_error_indicator
Payload_unit_start_indicator
Transport_priority
Adaption_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 mltiplo de 184 bytes, el ltimo paquete
de transporte de un paquete PES deber empezar por un campo de adaptacin (Adaptation Field,
AF), cuya longitud ser el complemento a 184 del nmero de bytes que queden por transmitir
para terminar este ltimo paquete PES, como se muestra en la figura 10.29.
Sync
8 Byte
Indicador de
Error de
Transporte
Indicador de
Comienzo
Prioridad de
Transporte
PID Control de
Scrambling
Control del
campo de
Adaptacin
Contador de
Continuidad
Campo de
Adaptacin
Payload
3 1 1 1 13 2 2 4
Header Payload
Indicador de
Discontinuidad
Indicador de
prioridad de
elementos de
la cadena
5 flags
Campo
opcional
8 1 1 1 5
Stuffing
Bytes
Indicador de
Acceso
aleatorio
Longitud del
Campo de
Adaptacin
188 bytes
48 8
Extensin del
Campo de
Adaptacin
Datos
privados de
Transporte
Contador
descente
OPCR PCR
48
Campo Definicin (comentario) N de bits
sync_byte byte de sincronizacin 1000 0111 (47 hex) 8
ei transport_error_indicator (indica un error detectado mas
atrs)
1
pusi payload_unit_start_indicator (inicio de PES en el
paquete)
1
tpr transport_priority (indicador de prioridad) 1
PID Packet IDentifier (identificacin del paquete) 13
scr_flags transport_scrambling_flags (tipo de cifrado de
transporte)
2
af adaptation_field_flag (campo de adaptacin 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 Constitucin del ltimo paquete de transporte de un PES
Adems de esta funcin de relleno, el campo de adaptacin se utilizara tambin para la transmi-
sin del reloj de referencia del programa (Program Clock Reference, PCR), cuya cadencia de
repeticin mnima es de 10 por segundo, as como diversos tipos de datos opcionales.
Un paquete de transporte eventualmente podr estar constituido nicamente por un campo de
adaptacin, de 184 bytes en este caso concreto (transporte de datos privados, PCR, etc.).
La figura 10.30 ilustra el formato general del campo de adaptacin, cuyo contenido se especifica
en la tabla 10.8.
Figura 10.30 Detalle del campo de adaptacin
Tabla 10.8 Constitucin del campo de adaptacin MPEG-2
Como ya se ha visto, un mltiplex 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-2
define cuatros tipos de tablas, que juntas constituyen la informacin especifica de los programas
(Program Especific Information, PSI).
PES Final del PES
X
H
Paquete de
Transporte
AF
184-X
PES
Longitud del campo de adaptacin
...
Y
1 1 X Y-X-1 bytes
Y
Flags
Campos opcionales Relleno
Campo Definicin N de bits
adaptation_field_length longitud total en bytes, menos 1 (y) 8
flags
marcadores que indican la informacin
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 transportada
por los paquetes cuyo indicador lleve el nmero 0 (PID= 0x0000). Su funcin es la de indi-
car, para cada programa transportado por el mltiplex de transporte, la relacin entre el
nmero de programa y el PID de los paquetes que transportan una tabla que indica los datos
que identifican el programa (Program Map Table, PMT). La PAT siempre se transmite "de
forma clara", aunque todos los programas estn cifrados.
2.- Program map table (PMT). Existe una tabla presente por cada programa en el mltiplex.
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 que
al menos un programa sea de acceso condicional. Se transporta por los paquetes de
PID=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 los
programas de acceso condicional). La norma MPEG-2 prev la posibilidad de aadir infor-
maciones complementarias opcionales (DVB-SI, Service Information) que permiten que el
receptor se configure automticamente, 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 informacin de red, cuyo contenido no est defi-
nido por MPEG, transporta informaciones especificas relativas a una red formada por varios
canales fsicos (por tanto, varios trenes de transporte independientes), tales como las frecuencias,
los nmeros de los canales de red utilizados en la configuracin del receptor.
Esta tabla, si est presente, constituye por definicin el programa 0 del mltiplex y es conside-
rada como datos privados.
Service description table (SDT). Esta tabla lista los nombres y otros parmetros asociados a cada
servicio de un mismo mltiplex.
Event information table (EIT). Esta tabla se utiliza para trasmitir informacin relativa a los acon-
tecimientos en curso o que vendrn en el mltiplex MPEG recibido y, ocasionalmente, sobre
unos mltiplex MPEG.
Time and date table (TDT). Esta tabla se utiliza para poner en hora el reloj interno del receptor
(decodificador).
Tambin permite una serie de tablas opcionales, que se describen a continuacin.
Tablas opcionales DVB-SI
Bouquet association table (BAT). Esta tabla se utiliza para agrupar la presentacin 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 actualizacin rpida 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 repeticin de las tablas no viene impuesta por la norma, no obstante, debe ser
suficiente (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 informacin de algunas tablas (PAT, PMT) podrn eventualmente ser almacenadas en una
memoria no voltil del decodificador para permitir un acceso ms rpido tras la puesta en mar-
cha. Posteriormente, esta memoria deber actualizarse cuando se produzcan modificaciones
espordicas en el contenido del mltiplex.
Cada tabla est constituida, segn su importancia, por una o varias secciones (256 como mximo,
con una longitud mxima de 1024 bytes, salvo para la tabla private que puede alcanzar los 4026
bytes).
La figura 10.31 muestra la manera en que utilizan las tablas constituyendo una PSI.
Figura 10.31 Estructura PSI
Programa 0
Tabla de
asosiacin de
programas
(PID 0)
16
Programa 1 22
Programa 3 33
Programa k 55
Datos
privados
de red
Tabla de
informacin
de red
Stream 1 54 Vdeo
Stream 2 48 Audio
Stream 3 49 Audio
Stream k Datos
Stream 1 54 Vdeo
Stream 2 48 Audio
Stream 3 49 Audio
Stream k Datos
Tablas de aplicacin
de programa (PMT)
Prog 1
PMT
Prog 3
PMT
PAT
Prog 1
Audio 2
EMM
Prog 3
Audio 2
Prog 3
Vdeo 1
Prog 3
Vdeo 1
Prog 1
Vdeo 1
Prog 3
Audio 1
Prog 3
Vdeo 1
0 22 33 1 49 82 19 19 54 81 19
Datos de acceso
condicional
Tabla de acceso
condicional (PID 1)
Al contrario que en los PES, las secciones no empiezan y acaban forzosamente con un paquete de
transporte. Cuando una seccin o un PES empieza en un paquete, el indicador
payload_unit_star_indicator (PUSI) se pone a "1".
Cuando se trata de una seccin, el paquete puede empezar al final de otra seccin, precedida o no
de un campo de adaptacin (adaptation_field). El primer byte de la "carga til" (payload) es un
indicador llamado pointer_field el que da el desplazamiento (offset) del comienzo de la nueva
seccin con respecto a este byte.
La figura 10.32 ilustra el caso donde una seccin empieza en un paquete de transporte, despus
de un campo de adaptacin (AF) y el final de una seccin anterior.
Figura 10.32 Caso general del comienzo de seccin en un paquete de transporte
Las principales etapas que hay que seguir para encontrar un programa o servicio en un mltiplex
de transporte MPEG-2, una vez que el mltiplex ha sido capturado (sintonizado en un canal).
Formato del MPEG-4
El estndar MPEG difiere sustancialmente tal y como se indic anteriormente. Por ello especifica
un Formato Binario para Escenas, BIFS, BInary Format for Scenes que se utiliza para describir la
informacin de la composicin 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 elementos
de la escena y las relaciones entre ellos forman el grafo de la escena, que debe codificarse para la
transmisin. Los elementos fundamentales del grafo de la escena son los nodos que describen las
primitivas audiovisuales y sus atributos, junto con la estructura del propio grafo de la escena.
La descripcin de las escenas se estructura en rbol basndose en la tecnologa VRML (Virtual
Reality Modeling Language).. El lenguaje VRML, diseado como un formato de fichero para
describir modelos y escenas 3D (mundos en su terminiloga). Sin embargo, carece de algunas
caractersticas necesarias para diversas aplicaciones multimedia a las que se aplica el MPEG-4.
En particular, el soporte para vdeo y audio natural es bsico. Por ejemplo, la secuenciacin de
los objetos de audio o vdeo no est soportada. Adems la especificacin del modelo de tempori-
zacin es pobre, implicando que no puede garantizarse la sincronizacin en una escena con ml-
tiples tipos de medios. Adems, los mundos VRML son a menudo muy grandes. Las
animaciones que tardan alrededor de 30 segundos consumen tpicamente varios megabytes. La
potencia de VRML radica en sus capacidades de descripcin del grafo de la escena y sobre ella se
ha construido la base con la que se ha construido la descripcin de la escena en MPEG-4.
Point_field
H AF
Comienzo de seccin
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, slo ECMAScript. Sin embargo, BIFS
ampla significativamente las capacidades de VRML de manera que permite un rango de aplica-
ciones mucho mayor. Obsrvese que una diferencia fundamental entre los dos es que BIFS tiene
formato binario mientras que VRML es tipo texto. As, aunque es posible disear escenas que
sean compatibles con BIFS y VRML, es necesario transcodificar los formatos.
Seguidamente se destacan las funcionalidades de BIFS que se aaden al conjunto bsico del
VRML.
1.- Formato binario comprimido: BIFS describe la informacin del grafo de la escena con una
eficiente representacin binaria. La codificacin puede ser con o sin prdidas. La eficiencia
de la codificacin se debe a un conjunto de tcnicas clsicas de compresin y algunos nue-
vos. El conocimiento del contexto se explota ampliamente en BIFS. Esta tcnica se basa en
el hecho de que dado algn 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.- Secuenciacin. BIFS se dise tal que la escena puede transmitirse como un escena inicial
seguida de las modificaciones a la misma. Para escenas dinmicas que cambian con el
tiempo esto repercute en una gran mejora en el uso de la memoria as como en reducir la
latencia respecto a las escenas VRML equivalentes. El protocolo BIFS Command permite
reemplazar la escena entera, sumar, eliminar o reemplazar los nodos y los elementos del
entorno en el grafo de la escena as como modificar las propiedades de la escena.
3.- Animacin. Se dise un segundo protocolo de secuenciacin, denominado BIFS Anim,
para proporcionar mecanismos para la animacin contnua
4.- Primitivas 2D. BIFS incluye soporte nativo para las escenas 2D. Esto facilita a la creacin
de contenidos con escenas de baja complejidad, incluyendo la televisin tradicional y las
industrias multimedia.
5.- Audio realzado. VRML ofrece un nico soporte de audio. Este soporte ha sido mejorado en
el MPEG-4. BIFS proporciona la nocin de un grafo de escenario de audio en la que pueden
mezclarse las fuentes de audio, incluyendo las secuenciaciones. Tambin proporciona un
interface de nodos para varios objetos de audio MPEG-4. El contenido de audio puede
incluso procesarse y transformarse con procedimientos especiales para producir diferentes
efectos de sonido.
6.- Animacin Facial. BIFS proporciona soporte a nivel de escena para la animacin facial en el
decodificador MPEG-4. Un conjunto especial de nodos BIFS exponen las propiedades de
los rostros animados
10.6.3 FORMATO DE LOS ARCHIVOS QUICKTIME. MOV
Un archivo QuickTime es simplemente una coleccin de tomos. QuickTime no impone ninguna
norma 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 la
extensin mov. En las plataformas Macintosh tienen un tipo de archivo
Cada tomo pertenece a un tipo determinado. Algunos tomos se consideran tipos bsicos y for-
man la estructura dentro de otros tomos que estn almacenados. La tabla 10.10 muestra los tipos
de tomos bsicos soportados.
Tabla 10.10 Tipos de tomos bsicos.
Aunque es verdad que QuickTime no impone un orden estricto sobre los tomos del vdeo, fre-
cuentemente es conveniente establecerlo si los tomos de pelcula aparecen cerca del principio
del fichero. Por ejemplo, una aplicacin que reproduce una pelcula sobre una red necesitara
tener acceso a la pelcula completa todo el tiempo, Si el tomo de pelcula se almacena al princi-
pio del fichero, la aplicacin puede utilizar los meta datos para entender los contenidos de la pel-
Datos del tomo de pelcula Bytes
Tamao del tomo 4
Type = 'mdat' 4
Datos Variable
M

tomo de pelcula 4
Tamao del tomo 4
Type = 'moov' Variable
Datos

Tipo de
tomo
Utilizacin
'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 tamao
extendido.
'pnot' Referencia a datos de previsionado de la pelcula
moov'
Recurso de pelcula los datos sobre la pelcula (nmero y tipo de pista,
localizacin de los datos muestras, etc.)
'mdat'
Datos de pelcula usualmente estos datos pueden interpretarse slo
utilizando los recursos de la pelcula.

cula mientras se adquiere a lo largo de la red. Esto puede permitir que la aplicacin reproduzca la
pelcula 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 pelcula.
Estos tomos constan slo de una cabecera que indica el tamao del tomo y los campos tipo. A
continuacin contiene el nmero de bytes de espacio libre. Cuando se lee una pelcula Quicktime
la aplicacin 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 slo de tipo y tamao de campo. Esto ocupa 8 bytes, espacio suficiente
para aadir un campo tamao extendido a la cabecera del tomo siguiente. Si un tomo crece y
excede los 232 bytes, y es precedido por un tomo wide, puede crearse una nueva cabecera de
tomo que contenga un campo de tamao extendido sobrescribiendo al tomo wide.
tomos de datos de pelcula.
Como en los tomos anteriores, la estructura de los tomos de datos de pelcula es bastante senci-
lla. Constan de una cabecera que indica el tamao del tomo y los campos tipo seguidos por los
datos de la pelcula. La aplicacin puede entender los datos sin ms que consultar los datos alma-
cenados. Este tomo puede ser bastante grande, y puede exceder los 232 bytes en cuyo caso el
campo de tamao se colocar a 1 y la cabecera contendr un tamao de campo extendido a 64
bits.
tomos de previsin, preview.
Estos tomos contienen la informacin que permite encontrar el previsionado o pster de la ima-
gen asociada a la pelcula La tabla 10.11 muestra la capa de un tomo preview.
Tabla 10.11 Capa de un tomo preview.
El tomo de previsualizacin tiene un valor del tipo de tomo 'pnot' y le sigue su tomo de cabe-
cera que contiene los siguientes campos:
Descripcin de campo
Size. Tamao. Es un entero de 32-bit que especifica el nmero de bytes en este tomo preview.
tomo preview Bytes
Tamao del tomo 4
Type = 'pnot' 4
Modificacin de datos 4
Nmero de versin 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 modificacin. Es un entero sin signo de 32-bit que contiene un dato
que indica cuando fue la ltima actualizacin de la previsualizacin.
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-
lizacin. 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 le
previsualizacin. Normalmente este campo es colocado a 1 para indicar que se usar el primer
tomo del tipo especificado.
Los tomos de pelcula de QuickTime actan como contendores para la informacin que describe
los datos de la pelcula. Esta informacin, o meta-datos, se almacena en varios tipos diferentes de
tomos. El tomo de pelcula es esencialmente un contenedor de otros tomos. En el nivel ms
alto, los tomos de pelcula generalmente contienen tomos de seguimiento, y en el nivel menor
los 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 edicin, que contienen un
tomo que contiene la denominada lista de edicin de tomos. La figura 10.33 muestra el
esquema de una pelcula Quicktime con una nica pelcula. Cada caja anidada representa un
tomo que pertenece a su tomo padre.
Debe tenerse en cuenta que esta descripcin corresponde al estndar. Si se trabaja con el API
Quicktime no es necesario considerar los tomos ya que puede utilizarse la funciones de tomos
para 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 EDICIN DE VDEO Y EL MERCADO DE CONSUMO
En 1996, Sony y Panasonic presentaron el primer formato DV y cambiaron para siempre el video
profesional y de consumo. Por primera vez, la grabacin de video con calidad digital estaba dis-
ponible a precios accesibles. El formato DV era ms pequeo que el MotionJPEG y ste tomaba
video directamente de la cinta con toda conversin anloga a digital realizada por circuitos de la
cmara de vdeo digital. Adems, las cmaras DV incorporaban una interfase completamente
digital llamada IEEE-1394, tambin iLINK o Firewire, para transferir el video y el audio pura-
mente digital directamente al PC con sincrona perfecta. Otras mejoras en la ptica de la cmara
y CCDs produjeron un salto significativo en la calidad desde las fuentes de estndares analgicos
S-video/Hi8.
El resultado fue la digitalizacin pura en la toma, edicin y distribucin, alcanzable a un mdico
precio. El DV estndar elimin las conversiones analgico-digital- analgico previamente reque-
ridas con MotionJPEG y disminuy la velocidad de bits de la secuencia de video a un valor de
3.7MB por segundo en lugar de los 7MB por segundo del MotionJPEG de similar calidad. Dado
que la conversin analgico -digital y digital- analgico reduce la calidad, el formato DV man-
tiene la ms alta calidad posible.
Figura 10.33 Esquema de una pelcula Quicktime con una nica pelcula.
La baja velocidad de datos implica que no se debe gastar demasiado en configurar el sistema de
edicin DV, porque pueden usarse componentes de bajo costo. Ms an, como los profesionales
y utilizan cmaras DV y cmaras analgicas, parece tener mas sentido editar los contenidos ana-
lgicos y DV juntos en formato DV. Esto mantiene los contenidos digitales puros y reduce el
tamao de la compresin del video analgico en el sistema.
Con la aceptacin del formato de pelculas DVD y la televisin Directa Digital en el mercado de
consumo, el formato de compresin MPEG 2 fue considerado como un formato posible de edi-
cin de video. Esto parece lgico porque ofrece una calidad superior de video comparado con las
cintas corrientes de VHS, emisin de televisin y hasta discos lser. Un obstculo significativo
del MPEG-2 es que, a diferencia del DV donde la velocidad de datos y la calidad de imagen son
consistentes a travs de todas las implementaciones, la calidad de imagen del MPEG-2 puede
variar significativamente de acuerdo con el sistema de codificacin empleado y la capacidad de
procesamiento puesto a su disposicin.
Actualmente los sistemas de edicin MPEG-2 utilizan Main Profile a Main Level (MP &ML,
IBP) o Simple Profile a Main Level (SP &ML,IP). La ms alta calidad al ms bajo ancho de
banda 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 una
imagen completa, el decodificador MPEG-2 y el software de edicin deben reconstruir una ima-
gen completa a partir del ultimo marco I y la porcin cambiada representada en el marco P. Un
marco tpico B o P contiene solamente un 5% de los datos encontrados en un marco I. El marco
reconstruido pocas veces reproduce la misma calidad que el marco I completo. Es como mirar
una impresin fotogrfica. La imagen fotogrfica en si misma es de alta calidad pero si se hace
una copia o se edita la foto no se parte de la fotografa sino que se va al negativo para lograr una
ptima calidad. En el caso de la edicin MPEG-2 IBP, el negativo no existe y nunca fue tomado
en esa forma.
Para lograr la mejor calidad de salida es importante minimizar el nmero de veces que se con-
vierte el material inicial a otro formato en un proceso de edicin. Cada paso innecesario anal-
gico-digital o digital- analgico o bien la transcodificacin entre formatos de compresin,
produce un decrecimiento de la calidad. Adems, el esquema de compresin debe guardar
durante el proceso de edicin suficientes datos disponibles para conservar la integridad de la ima-
gen.
La mejor opcin para conseguir la ms alta calidad es mantener la informacin dentro del mismo
formato de adquisicin - si la fuente es digital, mantener el formato digital a travs de todo el
proceso de edicin - y mantener el mismo formato digital durante todo el proceso.

Tema10 PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Tema10 PDF

Cargado por

Copyright:

Formatos disponibles

Programa Oficial de Postgrado:

Master en Comunicaciones, Redes y Gestin de Contenidos

También podría gustarte