Habilitando la innovación - cecyt4.files.wordpress.com · 4.4.1 Documentos de la norma MPEG-4 32...

Habilitando la innovación

Una guía de fundamentos de MPEG y análisis de protocolos ► Primer

www.tektronix.com/video_audio i

Sección 1 Introducción a MPEG 1 1.1 Convergencia 1 1.2 Por que es necesaria la compresión 1 1.3 Principios de Compresión 1 1.4 Compresión en aplicaciones de Televisión 2 1.5 Introducción a la compresión de video digital 3 1.6 Introducción a la compresión de audio 5 1.7 Streams MPEG 6 1.8 Necesidad de monitoreo y análisis 7 1.9 Inconvenientes de la compresión 7

Sección 2 Compresión en Video 8 2.1 ¿Codificación espacial o temporal? 8 2.2 Codificación espacial 8 2.3 Ponderación 10 2.4 Scanning (exploración) 11 2.5 Codificación de Entropía 11 2.6 Un Coder espacial 12 2.7 Codificación temporal 13 2.8 Compensación de movimiento 14 2.9 Codificación bidireccional 16 2.10 Imágenes I-, P- y B- 16 2.11 Un compressor MPEG 18 2.12 Pre procesamiento 21 2.13 Wavelets 22

Sección 3 Compresión de Audio 23

3.1. El mecanismo de audición 23 3.2. Codificación sub banda 24 3.3 MPEG Capa 1 25 3.4 MPEG Capa 2 26 3.5 Codificación de transformada 26 3.6 MPEG Capa 3 27 3.7 Audio MPEG-2 27 3.8 Audio MPEG-4 27 3.9 AC-3 28

Sección 4 Las normas MPEG 29

4.1. ¿Que es MPEG? 29 4.2 MPEG-1 29 4.3 MPEG-2 30

4.3.1 Perfiles y niveles en MPEG-2 30 4.4 MPEG-4 32

4.4.1 Documentos de la norma MPEG-4 32 4.4.2 Codificación de objetos 32 4.4.3 Codificación de audio y video 34 4.4.4 Escalabilidad 35 4.4.5 Otros aspectos de MPEG-4 36 4.4.6 El futuro de MPEG-4 37

4.5 MPEG-7 38 4.6 MPEG-21 39


www.tektronix.com/video_audio ii

Sección 5 Streams elementales 40 5.1 Sintaxis del stream elemental de Video 40 5.2 Streams elementales de Audio 41

Sección 6 Streams elementales paquetizados o PES (Packetized Elementary Streams) 42

6.1 Paquetes PES 42 6.2 Estampado de tiempo 42 6.3 PTS/DTS 42

Sección 7 Streams de elemental 44

7.1 Grabación vs. Transmisión 44 7.2 Introducción a los streams de programa 44

Sección 8 Streams de transporte 45

8.1 La función del Stream de transporte 45 8.2 Paquetes 46 8.3 Referencia del reloj de programa o (Program Clock Reference) 46 8.4 Identificación de paquete o PID (Packet Identification) 47 8.5 Información específica del programa (Program Specific Information) 48

Sección 9 Modulación Digital 50

9.1 Principios de Modulación 50 9.2 Modulación Analógica 50 9.3 Modulación de Cuadratura 50 9.4 Sistemas de Modulación Digital Simple 51 9.5 “Llaveo” (Keying) de corrimiento de fase 51 9.6 Modulación de amplitud de cuadratura o QAM (Quadrature Amplitude Modulation) 52 9.7 Modulación de banda lateral vestigial o VSB (Vestigial Sideband Modulation) 53 9.8 División Multiplexada de frecuencias ortogonalmente codificadas o COFDM (Coded Orthogonal Frequency Division Multiplex) 53 9.9 Servicios integrados de transmisión de datos o ISDB (Integrated Services Data Broadcasting) 55

9.9.1 Sistema de satélite ISDB-S 55 9.9.2 Sistema de cable ISDB-C 55 9.9.3 Modulación terrestre ISDB-T 55 9.9.4 El ISDB en resumen 55

Sección 10 Introducción a DVB y ATSC 56

10.1 Una vista general 56 10.2 Remultiplexión 57 10.3 Servicio de Información o SI (Information Service) 57 10.4 Corrección de errores 58 10.5 Codificación de canal 59 10.6 Codificación interna 60 10.7 Transmitiendo dígitos 61


www.tektronix.com/video_audio iii

Sección 11 Transmisión de datos 62 11.1 Aplicaciones 62

11.1.1 Datos relacionados con los programas 62 11.1.2 Datos de oportunidad 62 11.1.3 Datos de red 63 11.1.4 TV mejorada 63 11.1.5 TV Interactiva 63

11.2 Encapsulamiento del contenido 63 11.2.1 Encapsulado de datos MPEG 63

11.2.1.1 Canalización de datos 63 11.2.1.2 Streaming de datos 63 11.2.1.3 DSMCC - Digital Storage Medium Command and Control (Instrucción y control del medio de almacenamiento digital) 64 11.2.1.4 MPE – Multi-protocol Encapsulation (Encapsulado con protocolos múltiples) 64 11.2.1.5 Carruseles 64 11.2.1.6 Carruseles de datos 65 11.2.1.7 Carruseles de objetos 66 11.2.1.8 Como se transmiten los objetos de los carruseles 67 11.2.1.9 Sincronización de datos MPEG-2 68

11.2.2 Encapsulado de datos DVB 68 11.2.3 Encapsulado de datos ATSC A/90 68 11.2.4 Encapsulado de datos ARIB 69

11.3 Transmisión de contenido de datos 69 11.3.1 Anuncio de DVB 70 11.3.2 Anuncio de ATSC 70

11.4 Presentación de contenido 70 11.4.1 Set Top Box intermediario (Middleware) 70 11.4.2 Plataforma DVB de multimedia para el hogar o MHP (Multimedia Home Platform) 71 11.4.3 ATVEF DASE 72 11.4.4 DASE 72

Sección 12 Prueba de MPEG 73

12.1 Requerimientos para las pruebas 73 12.2 Análisis de un stream de transporte 73 12.3 Vista jerárquica 74 12.4 Vista interpretada 76 12.5 Sintaxis y análisis de CRC 76 12.6 Filtraje 77 12.7 Análisis de temporalización 77 12.8 Pruebas al Stream elemental 79 12.9 Streams de bits que cumplen con Sarnoff ® 79 12.10 Análisis del stream elemental 80 12.11 Creando un stream de transporte 81 12.12 Generación de inexactitudes PCR 81

Glosario 82


www.tektronix.com/video_audio iv


www.tektronix.com/video_audio v


www.tektronix.com/video_audio 1

Sección 1 – Introducción a MPEG MPEG es una de las técnicas de compresión de audio y video más popula-

res debido a que no es una sola norma. En lugar de eso es un rango de

normas útiles para diferentes aplicaciones basadas en principios similares.

MPEG es un acrónimo de Moving Picture Experts Group que es parte del

comité técnico JTC1, establecido por la ISO (International Standards

Organization u Organización electrotécnica internacional) y la IEC (Interna-

tional Electrotechnical comisión o Comisión electrotécnica internacional). La

JTC1 es responsable de la tecnología de información. Dentro de la JTC1, el

subgrupo SG29 es el responsable de “la codificación de la información de

audio, imágenes e hipermedia”. Hay una buena cantidad de grupos de

trabajo dentro de la SG29, incluyendo el JPEG (Joint Photographic Experts

Group o Grupo de expertos en fotografía) y el grupo de trabajo 11 para la

compresión de imágenes en movimiento. El grupo ISO/IEC JTC1/ SG29/

WG11 es el MPEG.

MPEG puede ser descrito como la interacción de acrónimos. Como estable-

ce la ETSI, “El CAT es un indicador para permitirle al IRD encontrar los

EMMs asociados con los sistemas CA que lo usan”. Si puede entender esta

oración, entonces no necesita este libro!

1.1 Convergencia

Las técnicas digitales para audio y video han progresado rápidamente por

un buen número de razones. La información digital es más robusta y puede

ser codificada para eliminar substancialmente los errores. Esto significa que

las pérdidas por generaciones en grabación y las pérdidas por transmisión

pueden ser eliminadas. El disco compacto o CD fue el primer producto para

el consumidor en demostrar esto.

Mientras que el CD tiene una calidad de sonido mejorada con respecto a su

predecesor en vinil, la comparación en calidad por sí misma no es suficien-

te. Lo importante es que la grabación digital y las técnicas de transmisión

permiten la manipulación del contenido hasta un grado que es imposible de

lograr con el analógico. Una vez que el audio y el video son digitalizados, el

contenido quedará en forma de datos. Dichos datos pueden ser manejados

en la misma forma que cualquier otro tipo de datos; por ello, el audio y video

digitales han pasado a ser de la incumbencia de la tecnología de cómputo.

La convergencia de las computadoras con equipo de audio y video es una

consecuencia inevitable de las invenciones clave de cómputo y la modula-

ción de código de pulso o PCM (Pulse Code Modulation). La media digital

puede almacenar cualquier tipo de información por lo que resulta sencillo

utilizar un dispositivo de almacenamiento para cómputo para el video digital.

Las estaciones de trabajo no lineales fueron el primer ejemplo de una

aplicación de la tecnología convergente que no tiene un equivalente en el

mundo analógico. Otro ejemplo, multimedia, combina el almacenamiento de

audio, video, gráficos, texto y datos en el mismo medio, la multimedia no

tiene equivalente en el dominio analógico.

1.2 Por que es necesaria la compresión

El éxito inicial del video digital en aplicaciones de post-producción se debió

a que los altos costos del video digital fueron sobrepasados por la capaci-

dad de usar capas ilimitadas y su capacidad de efectos; sin embargo, la

producción normal de video digital genera cerca de 200 megabits por se-

gundo y esta relación de bits requiere una capacidad extensa para su

almacenamiento y un ancho de banda alto para su transmisión. El video

digital solo puede ser usado en aplicaciones más amplias si los requeri-

mientos de almacenamiento y ancho de banda pueden ser llenados; ese es

el propósito de la compresión.

La compresión es una forma de expresar el audio y video digitales usando

menos datos. La compresión tiene las siguientes ventajas:

► Se necesita una menor cantidad de almacenamiento por cantidad dada de material

de fuente.

► Cuando se trabaja en tiempo real, la compresión reduce el ancho de banda nece-

saria; adicionalmente, la compresión permite una transferencia más rápida que en

tiempo real entre la media, por ejemplo, entre cinta y disco.

► Un formato de grabación comprimido puede usar una menor densidad de

grabación y esto puede hacer que la grabadora sea menos sensible a

factores ambientales y mantenimiento.

1.3 Principios de Compresión

Hay dos técnicas fundamentalmente diferentes que pueden ser usadas para

reducir la cantidad de datos usados para transmitir información de conteni-

do. En sistemas de compresión prácticos, usualmente se usan combinados,

frecuentemente en formas muy complejas.

La primera técnica es mejorar la eficiencia de la codificación. Hay muchas

formas de codificar cualquier información dada y la mayoría de las repre-

sentaciones de datos de audio y video contienen una cierta cantidad de

redundancia. El concepto de entropía se discute más abajo.

Muchos trucos de codificación pueden usarse para reducir o eliminar la

redundancia; los ejemplos incluyen la codificación de longitud corrida y los

sistemas de codificación de longitud variable como los códigos de Huffman,

Cuando se usan adecuadamente esas técnicas son completamente reversi-

bles por lo que después de la descompresión los datos serán idénticos a los

de la entrada al sistema. A este tipo de compresión se le llama sin pérdida.

Los programas de archivado para computadora como PKZip emplean este

tipo de compresión.



Obviamente, la compresión sin pérdidas es ideal pero desafortunadamente usualmente no proporciona el grado de reducción de datos necesario para aplicaciones de audio y video; sin embargo, debido a que es sin pérdidas puede aplicarse en cualquier punto del sistema y frecuentemente se usa a la salida de datos de los compresores con pérdidas.

Si la eliminación de la redundancia no reduce los datos tanto como fuera necesario una parte de la información tendrá que ser descartada. Los sistemas de compresión con pérdidas logran la reducción de datos remo-viendo información que sea irrelevante o de menor relevancia. Estas no son técnicas generales que puedan ser aplicadas a cualquier stream de datos; la estimación de la relevancia solo puede hacerse en el contexto de la aplicación, entendiendo lo que los datos representan y como serán usados. En el caso de la televisión, la aplicación es la presentación de imágenes y sonidos a los sistemas de visión y audición humanos y los factores huma-nos deben ser bien entendidos para diseñar un sistema de compresión efectivo.

Una parte de la información de las señales de video no puede ser percibida por el sistema de visión humana y por ello será relevante en este contexto, Un sistema de compresión que descarta solo información irrelevante de la información de la imagen es conocido como visualmente sin pérdidas.

1.4 Compresión en aplicaciones de Televisión

Las señales de televisión, analógicas y digitales, siempre han representado mucha información y se han usado técnicas de reducción del ancho de banda desde el principio. Probablemente uno de los primeros ejemplos es el entrelazado. Para un número de líneas dadas y una determinada relación de refrescamiento de imágenes, el entrelazado ofrece una reducción de 2:1 en el ancho de banda requerido. El proceso es con pérdidas; el entrelazado genera “artifacts” causados por las interferencias entre la información verti-cal y temporal y reduce la resolución vertical utilizable de la imagen. A pesar de ello, la mayor parte de lo que es descartado es bastante irrelevante por lo que el entrelazado representó un cambio simple y muy valioso en su época, Desafortunadamente el entrelazado y los “artifacts” que genera son muy molestos para los sistemas de compresión digital más sofisticados, Mucha de la complejidad del MPEG-2 es producida por la necesidad de manejar señales entrelazadas y aún hay pérdidas significativas en eficiencia de codificación cuando se le compara con señales en progresivo.

El siguiente pasos evolutivo se dio con el advenimiento del color. Las cáma-ras de color producen señales en RGB por lo que nominalmente hay tres veces la cantidad de información que en una señal monocromática pero había el requerimiento de transmitir señales de color en el mismo canal usado para la señal monocromática.

La primera parte de la solución fue transformar la señal de RGB a una señal de brillantez (normalmente designada como “Y”) más dos señales de dife-rencia de color, U y V o I y Q. La generación de la señal de brillantez supu-so un gran avance hacia la resolución del problema de compatibilidad con los receptores monocromáticos pero el paso más importante hacia la reduc-ción del ancho de banda llegó con las señales de diferencia de color. Estas destacaron el hecho de que el sistema de visión humana usa sensores que son sensibles a la brillantez y que pueden “ver” una imagen de muy alta resolución. Otros sensores capturan información de color pero a mucha menor resolución. El resultado neto es que, dentro de ciertos límites, una imagen monocromática bien definida que represente la brillantez de una escena sobrepuesta a información de color menos definida o borrosa (me-nor ancho de banda) aparecerá como una imagen de color bien definida. No es posible aprovecharse de esto cuando se usan señales en RGB ya que cada señal contiene información tanto de brillantez como de color; sin embargo, en el espacio YUV, la mayoría de la información de brillantez es transportada en la señal Y y muy poca en las señales de diferencia de color. Por eso es posible filtrar las señales de diferencia de color y reducir drásti-camente la información a transmitir.

Lo anterior es un ejemplo de eliminación (en su mayoría) de información irrelevante. Bajo las condiciones de diseño de la visión, el sistema visual no responde significativamente a la información de alta frecuencia de las señales de diferencia de color por lo que pueden ser descartadas. Las transmisiones de color en NTSC solo transmiten cerca de 500 Hz en cada señal de diferencia de color pero las imágenes resultan adecuadamente definidas para muchas aplicaciones.

El paso final en el proceso de reducción del ancho de banda de NTSC y PAL es “esconder” las señales de diferencia de color en partes que no se usen del espectro de la señal monocromática. Aunque el proceso no es estrictamente sin pérdidas esto puede ser a través de incrementar la efi-ciencia de codificación de la señal.

Algunas de las técnicas en el mundo digital son muy diferentes pero se aplican principios similares. Por ejemplo, MPEG transforma las señales a un dominio diferente para permitir el aislamiento de información irrelevante. La transformación a un espacio de diferencia de color aún se emplea pero las técnicas digitales permiten el filtrado de la señal de diferencia de color para reducir la resolución vertical para un mayor ahorro.



► Figura 1-1

La Figura 1-1a muestra que en los sistemas de televisión tradicional, la señal RGB de la cámara se convierte en las componentes Y, Pb y Pr para la compresión y codificación de una señal analógica compuesta par la transmisión. En la Figura 1-1b se muestra el equivalente moderno. Las señales Y, Pb y Pr son digitalizadas y transportadas como señales Y, Cb y Cr en su forma SDI en el proceso de produc-ción antes de ser codificadas para la transmisión en MPEG. Claro que MPEG puede ser considerada por quien transmite como un reemplazo más eficiente para el video en compuesto. Además, MPEG tiene una mayor flexibilidad debido a que la relación de bits requerida puede ser ajustada de acuerdo con la aplicación. A relaciones de bits menores MPEG puede ser usado para videoconferencias y videoteléfonos.

La transmisión de video digital o DVB (Digital Video Broadcasting) y las normas de la ATSC (Advanced Television Systems Committee o Comité de sistemas de televisión avanzada) (las normas europeas y americanas originadas para la trans-misión de televisión digital) no serían viables sin la compresión debido a que el ancho de banda requerido sería demasiado grande. La compresión extiende el tiempo de reproducción del DVD (digital video/versatile disk o disco versátil de video digital) permitiendo contar con películas completas en un solo disco. La compresión también reduce el costo del ENG y otras contribuciones de la producción de televi-sión. DVB, ATSC y los discos de video digital (DVD) están basados en la compre-sión MPEG-2.

En la grabación de cintas una compresión moderada facilita la tolerancia y adiciona confiabilidad en Digital Betacam y Digital-S, mientas que en SX, DVC, DVCPRO y DVCAM, la meta es la miniaturización. En servidores de video basados en disco, la compresión disminuirá el costo de almacenamiento. La compresión también dismi-nuye el ancho de banda que permite que más usuarios tengan acceso al servidor. Esta característica también es importante para aplicaciones de VOD (video on demand o video en demanda)

1.5 Introducción a la compresión de video digital

En todo el material de programa real hay dos tipos de componentes de la señal: aquellas que son nuevos e impredecibles y los que pueden ser anticipados. Las componentes nuevas son llamadas “entropía” y es la información real en la señal. El resto es llamado redundancia porque no es esencial. La redundancia puede ser especial, como la que encontramos en las grandes áreas planas de la imagen en la que los pixeles adyacentes tienen casi el mismo valor. La redundancia también puede ser temporal y aquí es donde las similitudes entre imágenes sucesivas se usan. Todos los sistemas de compresión trabajan separando la entropía de la redundancia en el Encoder. Solo la entropía será grabada o transmitida y el Decoder calculará la redundancia de la señal transmitida. La Figura 1-2a (vea la siguiente página muestra este concepto.

Un Encoder ideal extraerá toda la entropía y solo esta será transmitida al Decoder. Un Decoder ideal entonces reproducirá la señal original. En la práctica, este ideal no puede ser alcanzado. Un Coder ideal sería complejo y provocaría un retraso muy grande con el fin de usar la redundancia tem-poral. En ciertas aplicaciones como la grabación o el broadcast, será acep-table cierto retraso pero no en videoconferencias. En algunos casos, un Coder muy complejo sería demasiado caro. De lo anterior se desprende el hecho de que no haya un sistema de compresión ideal.



► Figura 1-2 En la práctica se necesitará un rango de Coders que tengan un rango determinado de retrasos de procesamiento y complejidades. La potencia del MPEG es que no es un formato de compresión simple sino un rango de herramientas de codificación normalizadas que pueden ser combinadas en una forma flexible para satisfacer un rango de aplicaciones. La forma en la que la codificación es ejecutada se incluye en los datos comprimidos para que el Decoder pueda manejar automáticamente cualquier cosa que haya decidido hacer el Coder.

En MPEG-2 y MPEG-4 la codificación se divide en varios perfiles que tienen diferente complejidad y cada perfil puede ser implementado a diferente nivel dependiendo de la resolución de la imagen de entrada. En la Sección 4 se verán con detalle los perfiles y niveles.

Hay muchos formatos diferentes de video digital y cada uno tiene una relación de bits diferente. Por ejemplo, un sistema de alta definición puede ser de 6 veces la relación de bits de un sistema de definición estándar. Consecuentemente, saber tan solo la relación de bits de la salida de un Coder no es muy útil, lo que importa es el factor de compresión que es la relación entre la relación de bits de la entrada con respecto a la relación de bits comprimidos, por ejemplo 2:1, 5:1 y así sucesivamente.

Desafortunadamente el número de variables involucradas hace que sea muy difícil determinar un factor de compresión útil. La Figura 1-2a muestra esto para un Coder ideal: si se envía toda la entropía la calidad será buena, sin embargo, si el factor de compresión es incrementado con el fin de reducir la relación de bits no se enviará toda la entropía y la calidad decae-rá. Note que en un sistema comprimido cuando ocurre una perdida de calidad esto será brusco (Figura 1-2b). Si la relación de bits disponible es inadecuada es mejor evitar esa área reduciendo la entropía de la imagen de entrada. Esto puede hacerse mediante el filtrado. La pérdida de resolución causada por el filtraje es subjetivamente más aceptable que los artifacts de compresión.

Para identificar la entropía a la perfección un compresor ideal tendría que ser extremadamente complejo. Un compresor práctico puede ser menos complejo por razones económicas y deberá enviar más datos para asegurar el transporte de toda la entropía. La Figura 1-2b muestra la relación entre la complejidad del Coder y su desempeño. Entre mayor sea el factor de com-presión requerido, más complejo tendrá que ser el Encoder.



La entropía varía en las señales de video. La grabación de un locutor dando las noticias tiene muchas redundancias y es fácil de comprimir. En contraste es más difícil comprimir una grabación con hojas flotando en el aire o la de un estadio de football que está en movimiento constante por lo que habrá menos redundancia (más información o entropía). En cualquier caso, si toda la entropía no se envía habrá pérdida de la calidad. Así, podemos escoger entre un canal de relación de bits constante con calidad variable o un canal de calidad constante con relación de bits variable. Los operadores de redes de Telecomunicaciones tienden a preferir una relación de bits constante por razones prácticas pero se puede usar un “Buffer” de memoria para promediar las variaciones de entropía si la dismi-nución resultante en retraso es aceptable. Para la grabación una relación de bits variable puede ser más sencilla de manejar y los DVDs usan una rela-ción de bits variable usando el “Buffering” de tal forma que la relación de bits permanezca dentro de las capacidades del sistema de disco. La intracodificación (intra = dentro) es una técnica que explota la redundan-cia espacial o redundancia dentro de la imagen; la ínter codificación (inter = entre) es una técnica que explora la redundancia temporal. La Intra codifi-cación puede ser usada sola como en la norma JPEG para imágenes estáticas o combinada con la inter codificación como en MPEG. La intra codificación depende de dos características de las imágenes típi-cas. La primera es que no todas las frecuencias espaciales están presentes simultáneamente y segundo, que entre mayor sea la frecuencia espacial será más probable que la amplitud sea menor. La intra codificación requiere el análisis de las frecuencias espaciales en una imagen. Este análisis es el propósito de las transformaciones como las wavelets y el DCT (Discrete cosine transform. Transformada discreta de coseno). Las transformadas producen coeficientes que describen la magnitud de cada frecuencia espacial. Típicamente, muchos coeficientes serán cero o cerca de cero y pueden ser omitidos dando como resultado una reducción en la relación de bits. La inter codificación depende de encontrar similitudes entre las imágenes sucesivas. Si una imagen dada está disponible en el Decoder, la siguiente imagen puede ser creada enviando solo las diferencias en la imagen. Las diferencias de la imagen se incrementarán cuando se muevan los objetos pero esta magnificación puede ser contrarrestada usando la compensación de movimiento ya que un objeto en movimiento generalmente no cambia su apariencia mucho de una imagen a la siguiente. Si el movimiento puede ser medido una aproximación más cercana a la imagen actual puede ser creada corriendo parte de la imagen previa a una nueva localidad. El proceso de corrimiento es controlado por un par de valores de desplazamiento vertical y horizontal (conocidos en conjunto como vector de movimiento) que es transmitido al Decoder. La transmisión del vector de movimiento requerirá de menos datos que enviar los datos de la diferencia de imagen.

MPEG puede manejar imágenes tanto entrelazadas como no entrelazadas. Una imagen en algún punto del eje del tiempo es llamada “cuadro” sin importar si es un campo o un cuadro. El entrelazado no es ideal como fuente para la compresión digital ya que por si misma es una técnica de compresión. La codificación temporal se hace más compleja porque los pixeles en un campo están en diferente posición que los que están en el siguiente. La compensación de movimiento minimiza pero no elimina las diferencias entre las imágenes sucesivas. La diferencia de imagen es por sí misma una imagen espacial y puede ser comprimida usando una transformación basa-da en la intra codificación como se describió previamente. La compensación de movimiento simplemente reduce la cantidad de datos en las diferencias de la imagen. La eficiencia de un Coder temporal crece con la extensión del tiempo sobre la cual puede actuar. La Figura 1-2c muestra que si se requiere un factor de compresión alto se debe considerar una extensión de tiempo mayor en la entrada y por tanto se experimentará un mayor retraso de codificación. Claramente, las señales codificadas temporalmente son difíciles de editar ya que el contenido de una imagen de salida dada puede estar basado en los datos de imagen que fueron transmitidos un poco antes. Los sistemas de producción tendrán que limitar el grado de codificación temporal para permitir la edición y esta limitación a su vez limitará el factor de compresión disponible.

1.6 Introducción a la compresión de audio La relación de bits de un canal de audio digital en PCM es de tan solo unos 1.5 megabits por segundo, que es cerca del 0.5 % del de la del video digital. Con esquemas de compresión de video suaves como los de Betacam Digital, la compresión de audio resulta innecesaria; pero a medida que el factor de compresión se eleva, resulta importante comprimir también el audio. La compresión de audio aprovecha dos hechos. El primero es que en las señales típicas de audio, no todas las frecuencias estarán presentes simul-táneamente. Segundo, debido al fenómeno del enmascaramiento, la audi-ción humana no puede discernir todos los detalles de una señal de audio. La compresión de audio divide el espectro de audio por medio del filtraje y las transformadas e incluye menos datos cuando describe bandas en las cuales el nivel es bajo. Donde el enmascaramiento previene o reduce la audibilidad de una banda en particular, se necesitarán enviar aún menos datos.



► Figura 1-3 La compresión de audio no es tan fácil de lograr como la compresión de video debido a la agudeza de la audición. El enmascaramiento solo funcio-na adecuadamente cuando la mascarilla y los sonidos a enmascarar coinci-den espacialmente. La coincidencia espacial siempre estará presente en las grabaciones monoaurales pero no en las estereofónicas en las que las señales de bajo nivel aún pueden oírse si están en alguna parte del escena-rio sonoro. Consecuentemente, en los sistemas estéreo y surround sound es permisible un menor factor de compresión para una calidad dada. Otro factor que complica la compresión de audio es que las resonancias retrasa-das en altavoces de no muy alta calidad enmascaran los artifacts de com-presión. Probar un compresor con altavoces baratos nos dará resultados falsos y las señales que aparentemente son satisfactorias pueden ser decepcionantes cuando se escuchan en un buen equipo. 1.7 Streams MPEG La salida de un Coder MPEG simple de audio o video es llamada “stream elemental”. Un stream elemental es una señal infinitamente cercana a tiempo real. Por conveniencia, el stream elemental puede ser dividido en bloques de datos de tamaño manejable que forman un stream elemental paquetizado o PES (Packetized elementary stream). Esos bloques de datos necesitan información de header para identificar el inicio de los paquetes y deben incluir un estampado de tiempo debido a que la paquetización inte-rrumpe el eje del tiempo. La Figura 1-3 muestra que un PES de video y un número de PES de audio se pueden combinar para formar un stream de programa, asumiendo que todos los Coders están “amarrados” a un reloj común. El estampado de tiempo en cada PES puede usarse para asegurar el “lip-sync” entre el video y el audio. Los streams de programa tienen paquetes de longitud variable con encabezadores. Se pueden usar para transferencia de datos de y hacia discos duros y ópticos que esencialmente están libres de errores y en el que se esperan archivos de tamaños arbitra-rios. Los DVDs usan streams de programa. Para transmisión y broadcasting digital muchos programas y sus PES asociados

pueden multiplexarse en un stream de transporte simple. Un stream de transpor-te difiere de los streams de programa en que los paquetes PES se subdividen aún más en paquetes cortos de tamaño fijo y en que se pueden transportar programas múltiples codificados con diferentes relojes. Esto es posible ya que el stream de transporte tiene un mecanismo de referencia de reloj de programa o PCR (Program Clock Reference) que permite la transmisión de relojes múltiples, uno de los cuales será seleccionado y regenerado en el Decoder. Un stream de transporte de programa simple o SPTS (Single Program Transport Stream) también es posible y se le puede encontrar entre un Coder y un Multiplexor. Ya que el stream de transporte puede “amarrar” el reloj del Decoder al reloj del Encoder, el STPS es más común que el Stream de programa. Un stream de programa es más que solo un Multiplexor de audio y un PES de video. Además de audio y video comprimido y datos, un stream de transporte incluye metadata que describe el stream de bits. Esto incluye la Tabla de asociación de programas o PAT (Program Association Table) que enlista cada programa del stream de transporte. Cada entrada en la PAT apunta a una Tabla de mapeo de transporte o PMT (Program Map Table) que enlista los streams elementales que constituyen cada programa. Algunos programas serán abiertos pero algunos pueden estar sujetos al acceso condicional (encriptación) y esta información tam-bién será transportada por la metadata. El stream de transporte consiste de paquetes de datos de tamaño fijo; cada uno contiene 188 bytes. Cada paquete transporta un Código de identificador de programa o PID (Program Identifier Code). Los paquetes del mismo stream elemental tendrán el mismo PID, de tal forma que el Decoder (o Demultiplexor) pueda seleccionar el stream(s) elemental que quiera y des-echar los demás. La enumeración de continuidad de los paquetes asegura que cada paquete que sea necesario para decodificar un stream sea recibi-do. Será necesario un sistema de sincronización efectivo para que los decodificadores puedan identificar correctamente el inicio de cada paquete y deserialice el stream de bits en palabras.



1.8 Necesidad de monitoreo y análisis El stream de transporte MPEG es una estructura extremadamente compleja que usa tablas interrelacionadas e identificadores codificados para separar los programas y los streams elementales dentro de los programas. Dentro de cada stream elemental hay una estructura también compleja que le permite al Decoder distinguir entre, por ejemplo, vectores, coeficientes y tablas de cuantización. Las fallas pueden dividirse en dos categorías muy amplias. En la primera categoría el sistema de transporte entregará correctamente la información de un Encoder/Multiplexor a un Decoder sin errores de bit o jitter adicionado pero el Encoder/Multiplexor o el Decoder tendrá alguna falla. En la segunda categoría, el Encoder/Multiplexor y el Decoder estarán bien pero el transpor-te de datos de uno a otro será defectuoso. Es muy importante saber si la falla está en el Encoder/Multiplexor, el transporte o el Decoder si se quiere encontrar pronto la solución. Los problemas de sincronización como las pérdidas o la corrupción de los patrones de sincronía pueden evitar la recepción del stream de transporte completo. Los defectos en el protocolo del stream de transporte pueden evitar que el Decoder encuentre todos los datos para un programa, quizá se entregue la imagen pero no así el sonido. La distribución correcta de los datos con excesivo jitter puede causar problemas de temporalización en el Decoder. Si un sistema que está usando un stream de transporte MPEG falla, esta podría estar en el Encoder, el Multiplexor o en el Decoder. ¿Cómo se puede aislar la falla? Primero hay que verificar que el stream de transporte cumpla con las normas de codificación de MPEG. Si el stream no cumple con ellas, difícilmente se puede culpar a un Decoder del problema. Si el stream cum-ple con las normas, podría ser necesario checar el Decoder. Las herramientas para prueba de video tradicionales: el generador de señales, el monitor de forma de onda y el vectorscopio no son apropiados para analizar los sistemas MPEG excepto para asegurar que las señales de video que entran o salen del sistema MPEG son de la calidad adecuada. En lugar de lo anterior, un juego de fuentes de señales de prueba MPEG válidas será esencial para probar el equipo receptor y los Decoders. Con un analizador adecuado, el desempeño de los Encoders, sistemas de transmi-sión, Multiplexores y Remultiplexores podrá estimarse con un alto grado de confianza. Como reputado proveedor de equipo de prueba de alta calidad en la industria de video, Tektronix sigue proporcionando soluciones de prueba y medición a medida que la tecnología evoluciona dando a los usuarios de MPEG la confianza de que los sistemas comprimidos complejos están funcionando adecuadamente y permiten un diagnóstico rápido aún cuando no estén presentes.

1.9 Inconvenientes de la compresión La compresión MPEG es con pérdidas ya que lo que es decodificado no es idéntico al original. La entropía de la fuente varía y cuando es alta, el siste-ma de compresión puede dejar artifacts visibles cuando se decodifica. En la compresión temporal, se asume la redundancia entre imágenes sucesivas. Cuando el caso no es ese, el sistema puede fallar. Un ejemplo es el video de una conferencia de prensa en la que los destellos de las cámaras están presentes. Las imágenes individuales que contienen los destellos serán totalmente diferentes de las imágenes inmediatamente anteriores y poste-riores en los que los artifacts de codificación pueden volverse muy obvios. El movimiento irregular o muchos objetos moviéndose independientemente en la pantalla requerirán mucho ancho de banda de vector y este requeri-miento solo puede ser llenado reduciendo el ancho de banda disponible para los datos de imagen. De nuevo, puede haber artifacts visibles cuyo valor varia y depende del movimiento. Este problema frecuentemente ocurre en videos de deportes. Una cuantización poco precisa provocará un “conturing” de luminancia y pasterización del color. Esto puede verse como sombras “manchadas” y bloqueo de áreas grandes de color plano. Subjetivamente, los artifacts de compresión son más molestos que el deterioro relativamente constante provocada por los sistemas de transmisión analógicos. La única solución a esos problemas es reducir el factor de compresión. Consecuentemente, el usuario tendrá que hacer un juicio de valor entre la economía de un factor de compresión alto y el nivel de los artifacts. Además de extender el retraso de la codificación y la decodificación, la codificación temporal también produce dificultades para la edición. De hecho, un stream de bits MPEG no puede ser editado de forma arbitraria. Esta restricción aparece debido a que en la codificación temporal la decodi-ficación de una imagen puede requerir el contenido de una imagen anterior y este podría no estar disponible. El hecho de que las imágenes puedan estar fuera de la secuencia también complica la edición. Si se va a usar una codificación adecuada las ediciones se pueden hacer pero solo en puntos de edición que están relativamente distantes. Si se requiere una edición arbitraria, el stream MPEG deberá seguir un proceso de decodificar-modificar-recodificar que provocará una pérdida por genera-ción.



Sección 2 – Compresión en Video ► Figura 2-1 Esta sección muestra como la compresión de video está basada en la percepción del ojo. Algunas técnicas habilitadoras importantes como las transformadas y la compensación de movimiento son consideradas como una introducción a la estructura de un Coder MPEG.

2.1 ¿Codificación espacial o temporal? Como se vio en la Sección 1, la compresión de video puede aprovechar las redundancias tanto espaciales como temporales, en MPEG, la redundancia temporal es reducida primero usando las similitudes entre las imágenes sucesivas. Tanto como sea posible de la imagen actual, esta será creada o “predicha” usando información de las imágenes que ya se enviaron. Cuando se usa esa técnica solo es necesario enviar una imagen diferencial que elimina las diferencias entre la imagen actual y la predicha. La imagen diferencial entonces estará sujeta a la compresión espacial. Como algo práctico es más fácil explicar la compresión espacial antes de explicar la compresión temporal. La compresión espacial depende de las similitudes entre los pixeles adya-centes en las áreas planas de la imagen y en las frecuencias espaciales dominantes en áreas con patrones. El sistema JPEG usa solo la compre-sión espacial ya que está diseñada para transmitir imágenes estáticas individuales; sin embargo, JPEG puede ser usado para codificar una suce-sión de imágenes individuales para video. En la aplicación llamada “Motion JPEG”, el factor de compresión no será tan bueno como si se usara la codificación temporal pero el stream de bits será editable libremente en base a imagen a imagen.

2.2 Codificación espacial El primer paso en la codificación espacial es hacer un análisis de las fre-cuencias espaciales usando una transformada. Una transformada simple-mente es una forma de expresar una forma de onda en un dominio diferen-te, en este caso, en el dominio de la frecuencia. La salida de una transfor-mada es un juego de coeficientes que describen que tanto de una frecuen-cia dada está presente. Una transformada inversa reproducirá la forma de onda original. Si los coeficientes son manejados con suficiente exactitud, la salida de la transformada inversa es idéntica a la forma de onda original. La transformada mejor conocida es la Transformada de Fourier. Esta trans-formada encuentra cada frecuencia de la señal de entrada multiplicando la forma de onda de la entrada por una muestra de una frecuencia de “target” llamada “una función base” e integrando el producto. La Figura 2-1 muestra que cuando la forma de onda de entrada no contiene la frecuencia de target, la integral será 0 pero cuando la contiene la integral será un coefi-ciente que describe la amplitud de esa frecuencia componente. Los resultados serán como los que se describen si la frecuencia componen-te está en fase con la función base; sin embargo, si la frecuencia compo-nente está en cuadratura con la función base, la integral seguirá siendo cero por lo que es necesario hacer dos búsquedas por cada frecuencia con las funciones base en cuadratura entre sí para que cada fase de la entrada sea detectada.



► Figura 2-2. La transformada de Fourier tiene la desventaja de requerir coeficientes para las componentes tanto de seno como de coseno de cada frecuencia. En la transfor-mada de coseno, la forma de onda de la entrada es una imagen especular en tiempo consigo misma antes de ser multiplicada por las funciones base. La Figura 2-2 muestra como esta imagen especular cancela todas las componentes senoida-les y duplica todas las componentes coseno. La función de base senoidal es innecesaria y solo se necesita un coeficiente para cada frecuencia. La transformada discreta de coseno o DCT (Discrete Cosine Transform) es la versión muestreada de la transformada de coseno y se usa extensamente en forma bidimensional en MPEG. Un bloque de 8x8 pixeles es transformado para convertirse en un bloque de 8x8 coeficientes. Ya que la transformada requiere la multiplicación por fracciones, hay una extensión de longitud de palabra que da como resultado coeficientes que tienen una mayor longitud de palabra que los valores de píxel. Típicamente un bloque de pixeles de 8 bit dará como resultado un bloque de coeficientes de 11 bits. Así, un DCT no dará como resultado ninguna

compresión, de hecho provoca lo opuesto; sin embargo, el DCT convierte los pixeles de la fuente a una forma en la que la compresión es más simple. La Figura 2-3 muestra los resultados de una transformada inversa de cada uno de los coefi-cientes individuales de un DCT de 8x8. En el caso de la señal de luminancia, el coeficiente superior izquierdo es la brillantez promedio o componente de DC de todo el bloque. Moviéndose por la fila superior, la frecuencia especial horizontal se incrementa. Moviéndose hacia abajo por la columna de la izquierda, la frecuencia especial vertical se incrementa. En las imágenes reales, diferentes frecuencias espaciales verticales y horizontales podrán ocurrir simultáneamente y un coeficiente en algún punto dentro del bloque representará todas las posibles combinaciones horizontal y vertical. La Figura 2-3 también muestra 8 coeficientes como formas de onda horizontales unidimensionales. Combinando esas formas de onda con varias amplitudes y cualquier polaridad se pueden reproducir cualquier combinación de 8 pixeles. Así, combinando 64 pixeles de la DCT en 2D tendremos como resultado el bloque original de 8x8 pixeles.



► Figura 2-3. Claro que para imágenes en color, las muestras de diferencia de color también tendrán que manejarse. Los datos de Y, Cb y Cr se ensamblan en arreglos de 8x8 y se transforman individualmente. En material de programa, muchos de los coeficientes tendrán valores de 0 o muy cercanos y por tanto no serán transmitidos. Este hecho da como resul-tado una compresión significativa que virtualmente es sin pérdidas. Si se necesita un factor de compresión mayor, entonces la longitud de palabra de los coeficientes que no son 0 deberá reducirse. Esta reducción hará dismi-nuir la exactitud de esos coeficientes e introducirá pérdidas al proceso. Con cuidado, las pérdidas pueden introducirse en una forma que sea muy poco visible para el espectador.

2.3 Ponderación La Figura 2-4 muestra que la percepción humana del ruido en las imágenes no es uniforme sino que está en función de la frecuencia espacial: más ruido puede ser tolerado a mayor frecuencia espacial; además, el ruido de video es enmascarado efectivamente por el detalle fino en la imagen mien-tras que en las áreas planas es altamente visible. El lector debe estar conciente de que las mediciones tradicionales de ruido son ponderadas frecuentemente de tal forma que las mediciones técnicas se relacionen mejor con el resultado subjetivo. La compresión reduce la exactitud de los coeficientes y tiene un efecto similar a usar muestras de longitud de palabra menores en PCM; esto es, el nivel del ruido se eleva. En PCM el resultado de acortar la longitud de la palabra es que el nivel del ruido se eleva por igual a todas las frecuencias. A medida que el DCT divide la señal en diferentes frecuencias se hace posible controlar el espectro del ruido. En una forma efectiva los coeficientes de baja frecuencia se repre-sentarán en una forma más exacta que los coeficientes de alta frecuencia por medio de un proceso de ponderación. La Figura 2-5 muestra que en el proceso de ponderación los coeficientes del DCT son divididos por medio de constantes que son una función de una frecuencia bidimensional. Los coeficientes de baja frecuencia serán dividi-dos por números pequeños y los coeficientes de alta frecuencia por gran-des. Después de la división, el resultado será truncado al entero más cerca-no. Esto es una forma de recuantización, en ausencia de ponderación, esta recuantización tendrá el efecto de incrementar en forma uniforme el tamaño del paso de cuantización pero con la ponderación se incrementará el tama-ño del paso de acuerdo con el factor de división.

► Figura 2-4. Como resultado, los coeficientes que representan frecuencias espaciales bajas, son recuantizados con pasos relativamente pequeños y sufren de ruido ligeramente incrementado. Los coeficientes que representan frecuen-cias espaciales mayores son recuantizados con pasos grandes y sufren de más ruido; sin embargo, menos pasos implicarán que se necesiten menos pasos para identificar el paso y obtener la compresión. En el Decoder, los ceros de menor orden serán adicionados para regresar los coeficientes ponderados a su magnitud correcta. Entonces se multiplica-rán por factores de ponderación inversos. Muy claramente a frecuencias altas los factores de multiplicación serán mayores por lo que el ruido de recuantización será mayor. Después de la ponderación inversa los coefi-cientes tendrán sus valores de DCT originales más un error de recuantiza-ción que será mayor en alta frecuencia que en baja frecuencia. Como alternativa al truncado, los coeficientes ponderados pueden ser alinealmente recuantizados de tal forma que el tamaño del paso de cuanti-zación incremente la magnitud del coeficiente. Esta técnica permite factores de compresión más altos pero con peores niveles de artifacts. Claramente, el grado de compresión obtenido y, a su vez, la relación de bits de salida obtenida, será una función de la severidad del proceso de recuan-tización. Diferentes relaciones de bit requerirán diferentes tablas de ponde-ración. En MPEG es posible usar diferentes tablas de ponderación y la tabla en uso puede ser transmitida al Decoder para asegurar la decodificación correcta.



► Figura 2-5 2.4 Scanning (exploración) En material de programa típico, los coeficientes de DCT más significativos se encuentran generalmente en o cerca de la esquina superior izquierda de la matriz. Después de la ponderación los coeficientes de bajo valor pueden ser truncados a 0. Se puede obtener una transmisión más eficiente si se envían primero todos los coeficientes que no son 0 seguido por un código que indique que todo lo restante es 0. El “Scanning” o exploración es una técnica que incrementa la probabilidad de lograr ese resultado debido a que envía coeficientes en orden descendiente de magnitud de probabilidad. La Figura 2-6a muestra que en un sistema no entrela-zado, la posibilidad de un coeficiente que tenga un valor alto será más alto en la esquina superior izquierda (vea la siguiente página) y más bajo en la esquina inferior derecha. Una exploración en “zigzag” en diagonal a 45º es la mejor secuen-cia a utilizar. En la Figura 2-6b, se muestra un patrón de exploración alternativa que puede ser usado para Fuentes entrelazadas. En una fuente entrelazada, un

bloque DCT de 8x8 de un campo se extiende por dos veces el área vertical de la pantalla por lo que para un detalle de imagen dado, las frecuencias verticales parecerán dos veces más grandes que las frecuencias horizonta-les. Así, la exploración ideal para una imagen entrelazada será en diagonal que tiene un paso del doble de longitud. La Figura 2-6b muestra que una frecuencia espacial vertical dada es explorada antes de escanear la misma frecuencia espacial horizontal.

2.5 Codificación de Entropía En video real, no todas las frecuencias espaciales estarán presentes simul-táneamente por lo que la matriz de coeficientes de DCT contendrá términos en 0. La recuantización incrementará el número de ceros eliminando los valores pequeños.



► Figura 2-6 A pesar del uso del “scanning” o exploración, los coeficientes 0 seguirán apareciendo entre los valores significativos. La codificación de longitud corrida o RLC (Run Length Coding) permite manejar esos coeficientes más eficientemente. Donde se repiten los valores, como en los strings de ceros la RLC simplemente transmitirá el número de ceros en lugar de cada bit individual. La probabilidad de ocurrencia de valores de coeficientes particulares en el video real se puede estudiar. En la práctica, algunos valores ocurren muy frecuentemente y otros menos. La información estadística se puede usar para lograr una mayor compresión usando la codificación de longitud varia-ble o VLC (Variable Length Coding). Frecuentemente ocurren valores que son convertidos a palabras de código cortas y los valores infrecuentes se convierten a palabras de código largas. Para ayudar en la decodificación ninguna palabra de código puede ser el prefijo de otra.

2.6 Un Coder espacial La Figura 2-7 reúne todos los conceptos precedentes de codificación espacial. Se asume que la señal de entrada es SDI 4:2:2 SDI (Serial Digital Interface o Interfase serial digital), que puede tener una longitud de palabra de 8 o 10 bits. MPEG usa solo una resolución de 8 bit por lo que será necesaria una etapa de redondeo cuando la señal SDI contenga palabras de 10 bits. La mayoría de los perfiles de MPEG operan con el muestreo 4:2:0 por lo que será necesaria una etapa de filtraje/interpolación de pasa bajas vertical. El redondeo y el submuestreo de color introducen una pequeña pérdida irreversible de información y una reducción pro-porcional en la relación de bits. El formato de entrada del “raster” explorado necesi-tará ser almacenado de tal forma que pueda ser convertido a bloques de 8x8 pixeles.

► Figura 2-7



► Figura 2-8 El escenario DCT transforma la información de imagen al dominio de la frecuencia. El DCT por sí mismo no logra ninguna compresión. Después del DCT los coeficientes son ponderados y truncados proporcionando la prime-ra compresión significativa. Los coeficientes entonces se exploran en zigzag para incrementar la probabilidad de que los coeficientes significativos apa-rezcan pronto en la exploración. Después del último coeficiente que no sea cero, se genera un código de EOB (end of block, fin de bloque). Los datos de los coeficientes se comprimen aún más por medio de las codificaciones de longitud corrida o (run-length) y de longitud variable o (variable-length). En un sistema de relación de bits variable, la cuantización puede ser fijada pero en un sistema de relación de bits fija, se usa una memoria Buffer para absorber las variaciones en las dificultades de la codificación. Las imágenes muy detalladas tenderán a llenar el Buffer mientras que las planas permitirán que se vacíe. Si hubiera peligro de que el Buffer se desborde los pasos de recuantización tendrán que hacerse más grandes de tal forma que se eleve el factor de compresión. En el Decoder el stream de bits se deserializa y la codificación de entropía

se invierte para reproducir los coeficientes ponderados. Los coeficientes son colocados en la matriz de acuerdo a la exploración en zigzag y se aplica la ponderación inversa para recrear el bloque de coeficientes de DCT. Des-pués de la transformada inversa se recrea el bloque de 8x8 pixeles. Para obtener una salida de raster explorado, los bloques son almacenados en RAM los cuales serán leídos línea a línea. Para obtener una salida 4:2:2 de datos en 4:2:0 será necesario un procesamiento de interpolación vertical como se muestra en la Figura 2-8. Las muestras de croma en 4:2:0 son posicionadas a medio camino entre las muestras de luminancia en los ejes verticales de tal forma que queden espaciados equitativamente cuando se use una fuente entrelazada.

2.7 Codificación temporal La redundancia temporal puede ser explotada por la intercodificación o transmitir solo las diferencias entre las imágenes. La Figura 2-9 muestra que el retraso de una imagen combinado con un substractor puede calcular las diferencias de imagen.

► Figura 2-9



► Figura 2-10 La imagen diferencial es una imagen por derecho propio y se puede com-primir más con el Coder especial como ya se describió previamente. El Decoder invierte la codificación espacial y adiciona la imagen diferencial a la imagen previa para obtener la siguiente imagen. Hay algunas desventajas de este sistema simple. Primero, ya que solo se envían las diferencias es imposible comenzar a decodificar después del inicio de la transmisión. Esta limitación hace difícil que el Decoder propor-cione imágenes después de cambiar de un stream al otro (como ocurre cuando el espectador cambia de canales). Segundo, si cualquier parte de los datos de la diferencia es incorrecta, el error en la imagen se propagará indefinidamente. La solución a esos problemas es usa un sistema que no sea completamente diferencial. La Figura 2-10 muestra que se envían periódicamente imáge-nes completas. Estas imágenes son llamadas imágenes intra codificadas (o

imágenes I-) y se obtienen solo por medio de la compresión espacial. Si hay un error o un cambio de canal es posible reasumir la decodificación correcta en la siguiente imagen “I-”.

2.8 Compensación de movimiento El movimiento reduce las similitudes entre las imágenes e incrementa los datos necesarios para crear la imagen diferencial. La compensación de movimiento se usa para incrementar la similitud. La Figura 2-11 muestra este principio. Cuando un objeto se mueve por la pantalla de TV puede aparecer en diferente lugar a cada imagen pero no cambiará mucho su apariencia. La imagen diferencial puede ser reducida midiendo el movimien-to en el Encoder. Esta será enviada al Decoder como un vector. El Decoder usa el vector para correr parte de la imagen previa a un lugar más apropia-do en la nueva imagen.

► Figura 2-11



► Figura 2-12 Un vector controla el corrimiento de un área completa de la imagen que es conocida como “macrobloque”. El tamaño del macrobloque es determinado por la codificación DCT y la estructura del submuestreo de color. La Figura 2-12a muestra que con un sistema 4:2:0 el espaciado vertical y horizontal de las muestras de color es de exactamente el doble que el de la luminan-cia. Un bloque DCT simple de 8x8 muestras de color se extiende en la misma área que 4 bloques de luminancia 8x8 por lo que esta será el área de imagen mínima que podrá ser corrida por un vector. Un macrobloque 4:2:0 contiene 4 bloques de luminancia: un bloque Cb y un bloque Cr. En el perfil 4:2:2, el color solo es submuestreado en el eje horizontal. La Figura 2-12b muestra que en 4:2:2, un bloque DCT simple de 8x8 muestras de color se extiende por dos bloques de luminancia. Un macrobloque 4:2:2 contiene cuatro bloques de luminancia: dos bloques Cb y dos Cr.

El estimador de movimiento trabaja comparando los datos de luminancia de dos imágenes sucesivas. Un macrobloque en la primera imagen se usa como referencia. La correlación entre la referencia y la siguiente imagen se mide a todos los desplazamientos posibles con una resolución de medio píxel en el rango de búsqueda completo. Cuando se encuentra la mayor correlación, esta se asume que representa el movimiento correcto. El vector de movimiento tiene una componente vertical y una horizontal. Para material de programa típico, un objeto en movimiento puede extender-se a través de un número de macrobloques. Se obtendrá un factor de compresión mayor si los vectores se transmiten en forma diferencial. Cuando un objeto grande se mueve, los macrobloques adyacentes tienen los mismos vectores y el vector diferencial se hace 0.



Los vectores de movimiento están asociados con macrobloques no con objetos reales en la imagen y habrá ocasiones en las que parte del macro-bloque se moverá y parte no. En ese caso es imposible compensar adecua-damente. Si el movimiento de la parte que se está moviendo es compensa-do transmitiendo un vector, la parte estacionaria se correrá de forma inco-rrecta y necesitará datos diferenciales para ser corregido. Si no se envían vectores, la parte estacionaria será correcta pero los datos diferenciales serán necesarios para corregir la parte que se está moviendo. Un compre-sor práctico puede intentar aplicar ambas estrategias y seleccionar la que requiera de menos datos.

2.9 Codificación bidireccional Cuando un objeto se mueve, cancela el fondo en su contorno del frente y lo revela en el contorno posterior. El fondo revelado requiere que se transmi-tan nuevos datos debido a que el área del fondo fue cancelado previamente y no se puede obtener información de una imagen previa. Un problema similar ocurre si la cámara hace un paneo; nuevas áreas serán visibles y no se sabe nada de ellas. MPEG ayuda a minimizar este problema usando la codificación bidireccional que permite que se tome información de las imágenes que están antes y después de la actual. Si se revela un fondo este estará presente en una imagen posterior y la información se puede mover hacia atrás en el tiempo para crear parte de una imagen anterior. La Figura 2-13 muestra el concepto de codificación bidireccional. En base a macrobloques individuales, una imagen con codificación bidireccional puede obtener datos con compensación de movimiento de una imagen previa o posterior o, incluso, usar un promedio de datos anteriores o posteriores. La codificación bidireccional reduce significativamente la cantidad de datos diferenciales necesarios para mejorar el grado de predicción posible. MPEG no especifica como se debe construir un Encoder, solo lo que constituye un stream de bits que cumple con la norma; sin embargo, un compresor inteli-gente puede probar las tres estrategias y seleccionar la que proporcione menos datos a transmitir.

2.10 Imágenes I-, P- y B- En MPEG, se necesitan tres tipos diferentes de imágenes para respaldar la codificación diferencial y la bidireccional para minimizar la propagación de errores: Las imágenes I- son imágenes intracodificadas que no necesitan informa-ción adicional para decodificarlas; en cambio requieren muchos datos en comparación con otros tipos de imágenes y por lo tanto no se transmiten más frecuentemente que lo necesario. Consisten principalmente de coefi-cientes transformados y no tienen vectores. Las imágenes I- son decodifi-cadas sin referencias a ninguna otra imagen por lo que le permiten al es-pectador cambiar canales y detienen la propagación de errores.

► Figura 2-13 Las imágenes P- son predichas por adelantado a partir de una imagen anterior que puede ser una I- o una P-. Los datos de las imágenes P- con-sisten de vectores que describen donde, en la imagen previa, cada macro-bloque debe ser tomado y los coeficientes transformados que describen la corrección o datos diferenciales que deben ser adicionados a ese macro-bloque. Donde no se puedan encontrar coincidencias para un macrobloque por la búsqueda de la compensación de movimiento, los datos “intra” se envían para codificar ese macrobloque. Las imágenes P- requieren aproxi-madamente la mitad de los datos que una imagen I-. Las imágenes B- se predicen en forma bidireccional de una imagen I- o P- anterior o posterior. Los datos de las imágenes B- consisten de vectores que describen en que parte de las imágenes anteriores o posteriores se deben tomar los datos. También contienen los datos intracodificados que proporcionan las correcciones necesarias. De nuevo, cuando la búsqueda de compensación de movimiento no encuentra coincidencias, los datos “intra” se envían para codificar ese macrobloque. La predicción bidireccional es muy efectiva por lo que la mayoría de los macrobloques en una imagen B- serán codificados principalmente por vectores de movimiento. Además, una imagen B- nunca se usa como referencia para codificar otras imágenes por lo que no hay posibilidad de errores de propagación. Esto le permite a los Encoders usar una recuantificación más agresiva para la corrección de datos. Una imagen B- típica requiere aproximadamente una cuarta parte de los datos que una imagen I-. Hay que hacer notar que una imagen B- no tiene que usar ambas direccio-nes de la predicción; en algunas circunstancias solo se emplea una direc-ción. Esta opción se puede usar cuando se construyen grupos de imágenes o GOP (Groups Of Pictures) cerrados.



► Figura 2-14 La Figura 2-14 presenta el concepto de GOP. El GOP representa la estruc-tura de las imágenes I-, P- y B- en la secuencia. Generalmente la estructura del GOP se repite en la secuencia pero su longitud y estructura puede cambiar en cualquier momento. No hay límites formales para la longitud de un GOP pero para la transmisión una longitud típica será de 12 o 15 imáge-nes. La naturaleza de la compresión temporal de MPEG implica que el orden de transmisión de las imágenes no es el mismo que el orden de despliegue. Una imagen P- en forma natural seguirá a una I- o P- a partir de la cual es predicha, por lo que no habrá requerimientos especiales. Sin embargo, una imagen B- codificada bidirecionalmente no se puede decodificar hasta que sus dos imágenes de referencia se hayan recibido y decodificado. La Figura 2-14 muestra las imágenes de un GOP en su orden de despliegue en la parte superior y en la inferior en orden de transmisión. Note que en el orden de transmisión las imágenes B- siempre siguen a las dos imágenes de referencia de las que es predicha. Hay dos tipos de GOP: abiertos y cerrados. Un GOP cerrado no requiere referencias fuera de él. En el orden de despliegue puede comenzar con una imagen I- y terminar con una P-. En el orden de transmisión usualmente habrá imágenes B- después de la última imagen P- pero son imágenes que se desplegarán antes de la última imagen P-. Es posible empezar y/o terminar un GOP cerrado con imágenes B- (en el orden de despliegue) pero en el caso de iniciar y terminar con imágenes B- se debe codificar usando una sola dirección de predicción. Las imágenes B- al inicio de un GOP cerrado solo deben usar la predicción retrasada. Las imágenes B- al inicio de un GOP usado pueden usar solo la predicción adelantada, en forma similar a una imagen P- pero las reglas de las imáge-nes B- serán usadas para la recuantización, etc. Un GOP abierto no tiene esas restricciones en los vectores de predicción. Por ejemplo, las imágenes B- al final de un GOP pueden usar la predicción adelantada de la última imagen P- y la predicción retrasada de la primera imagen I- del siguiente GOP. Esta estructura es ligeramente más eficiente pero las predicciones cualquier frontera de imágenes. Es mucho más difícil

► Figura 2-15 dividir los streams de video y será más probable que los eventos como los cambios de canal causen errores de imagen. La estructura del GOP puede ser alterada por el Encoder cuando haya cambios de escena. Las predicciones a través de los cambios de escena usualmente fallarán ya que habrá grandes cantidades de entropía entre las dos imágenes a cualquier lado del cambio de escena. Un Encoder puede elegir detectar el cambio de escena, usar un GOP cerrado que nos lleve al cambio de escena e iniciar un nuevo GOP (abierto o cerrado) con una imagen I- para representar la primera imagen de la nueva escena. Enviar datos de imagen de una secuencia requiere memoria adicional al Encoder y Decoder y también causara retrasos. El número de imágenes codificadas bidirecionalmente entre intra o predichas por adelantado se deben restringir para reducir el costo y minimizar el retraso si esto resultara importante. La Figura 2-15 muestra el compromiso que se debe establecer entre el factor de compresión y el retraso de codificación. Para una calidad dada, enviar solo imágenes I- requerirá más de dos veces la relación de bits de una secuencia IBBP.



► Figura 2-16a 2.11 Un compresor MPEG Las Figuras 2-16a, b y c muestran la estructura de un compensador de movimiento bidireccional típico. El video de entrada preprocesado entra a una serie de almacenes de cuadros a los que se les puede hacer un “by-pass” para cambiar el orden de la imagen. Los datos entonces entrarán al substractor y al estimador de movimiento.

Para crear una imagen I-, el fin del retraso de entrada se selecciona y el substractor se desactiva de tal forma que los datos pasen directamente para ser codificados espacialmente (ver Figura 2-16a). La salida de datos del substractor también pasa a un almacén de cuadros que puede contener muchas imágenes. La imagen I- es mantenida en el almacén.



► Figura 2-16b Para codificar una imagen P-, se les aplica un “bypass” a las imágenes B- del Buffer de entrada para seleccionar la siguiente imagen futura (ver Figura 2-16b). El estimador de movimiento comparará la imagen I- en el almacén de salida con la imagen P- en el almacén de entrada para crear los vectores de movimiento adelantados. Los macrobloques de la imagen I- son corridos

por esos vectores para hacer una imagen P- predicha. La imagen P- predi-cha es substraída de la imagen P- real para producir el error de predicción que se codifica espacialmente y se envía junto con los vectores. El error de predicción también se adiciona a la imagen P- predicha para crear una imagen P- localmente decodificada que también entra al almacén de salida.



► Figura 2-16c El almacén de salida entonces contendrá una imagen I- y una imagen P-. Una imagen B- del “Buffer” de entrada podrá seleccionarse ahora. El com-pensador de movimiento comparará la imagen B- con la imagen I- que le preceda y la imagen P- que le sigue para obtener vectores bidireccionales (ver Figura 2-16c). La compensación de movimiento retrasada y adelantada es ejecutada para producir dos imágenes B- predichas. Estas serán subs-traídas de la imagen B- actual. En base a macrobloque a macrobloque, los

datos retrasados y adelantados son seleccionados de acuerdo a cuales representan las diferencias más pequeñas. Las diferencias de la imagen serán codificadas espacialmente y se envían con los vectores. Cuando todas las imágenes B- intermedias estén codificadas, se le volverá a hacer un “bypass” a la memoria de entrada para crear una nueva imagen P- basada en la imagen P- previa.



► Figura 2-17 La Figura 2-17 muestra un Coder MPEG. La salida del Compensador de movimiento se codifica espacialmente y los vectores son adicionados en un Multiplexor. Los datos sintácticos también se adicionan, lo que identificará el tipo de imagen (I-, P-, o B-) y proporcionará otra información para ayudar al Decoder (ver Sección 5 – Streams Elementales). La salida de datos es puesta en un “Buffer” para permitir variaciones temporales en relación de bits. Si la relación de bits media es demasiado alta el “Buffer” tenderá a llenarse. Para evitar el sobreflujo la cuantización tendrá que hacerse en una forma más severa. Igualmente, si el “Buffer” muestra signos de poco flujo se deberá relajar la cuantización para mantener la relación de bits promedio.

2.12 Pre procesamiento Un Compresor intentará eliminar la redundancia dentro de la imagen y entre ellas. Cualquier cosa que reduzca la redundancia aparente, que no sea contenido de imagen, no es deseable. El ruido y el grano de la película son particularmente problemáticos porque en general ocurren en toda la ima-gen. Después del proceso de DCT, el ruido dará coeficientes diferentes de cero y el Coder no podrá distinguir esta información de los datos genuinos de imagen. Una cuantización más pesada se requerirá para codificar todos los coeficientes reduciendo la calidad de imagen. El ruido también reduce las similitudes entre las imágenes sucesivas incrementando la diferencia de datos necesaria. La subportadora residual en el video decodificado de video compuesto es un problema serio porque dará como resultado frecuencias espaciales altas que normalmente están a bajo nivel en programas en componentes. La subportadora también se alterna en fase de imagen a imagen causando un incremento en los datos diferenciales. Naturalmente, cualquier “artifact” de decodificación en compuesto que sea visible a la entrada del Coder MPEG es muy probable que sea reproducido en el Decoder.

Cualquier práctica que provoque movimiento no deseado hay que evitarla. Los montajes de cámara inestables, además de darnos una imagen temblo-rosa incrementarán las diferencias de la imagen y los requerimientos de transmisión de vectores. Esto también pasará con el material de telecine si el daño de los orificios de la rueda dentada provoca ondulaciones de cinta o brincos. En general el video que se va a comprimir debe ser de la más alta calidad posible. Si no se puede lograr eso entonces será deseable la reduc-ción de ruido y otras técnicas de estabilización. Si se requiere un alto factor de compresión, el nivel de artifacts se puede incrementar especialmente si la calidad de entrada es pobre. En ese caso lo mejor podría ser reducir la entropía presentada al Coder usando el pre filtraje; en él la señal de video estará sujeta a un filtraje bidimensional pasa bajas con lo que se reducirá el número de coeficientes necesarios y se reducirá el nivel de los artifacts. La imagen se verá menos definida pero es preferible a un alto nivel de artifacts. En la mayoría de aplicaciones de MPEG-2 se usa el muestreo 4:2:0 por lo que se requerirá un proceso de “downsampling” de croma si la fuente está a 4:2:2. En MPEG-1, la Luminancia y la Croma atraviesan un proceso de “downsamping” mayor para producir una imagen de entrada o CIF (Com-mon Image Format, Formato de imagen común) que es de solo 352 pixeles de ancho. Esta técnica reduce la entropía en un factor mayor. Para una compresión muy alta se usa el QCIF (Quarter Common Image Format o Formato de imagen de un cuarto del común), que es de 176 pixeles de ancho. El “Downsampling” es un proceso que combina un filtro pasa-bajas espacial con un interpolador. El “Downsampling” de señales entrelazadas es problemático porque el detalle vertical es esparcido por dos campos que se puede decorrelacionar debido al movimiento.



Cuando el material de fuente es telecine, la señal de video tiene diferentes características que el video normal. En el video a 50 Hz, los pares de campos representan el mismo cuadro de película y no hay movimiento entre ellos. Así, el movimiento entre los campos se alterna entre cero y el movimiento entre los cuadros. En el video a 60 Hz se usa un “pulldown” 3:2 para obtener 60 Hz de película a 24 Hz. Un cuadro se convierte en dos campos; el siguiente en tres campos y así sucesivamente.

Consecuentemente, un campo de cada cinco es completamente redundan-te. MPEG maneja mejor el material de cine descartando el tercer campo en los sistemas 3:2. Un código de 24 Hz en la transmisión alertará al Decoder que debe recrear la secuencia 3:2 volviendo a leer un almacén de campos. En el telecine a 50 y 60 Hz los pares de campos son desentrelazados para crear cuadros y luego el movimiento se mide entre los cuadros. El Decoder puede recrear el entrelazado leyendo líneas alternadas en el almacén de cuadros. Un corte es un evento difícil de manejar para el Compresor porque frecuen-temente provocará una falla de predicción casi completa y se requerirá una larga cantidad de corrección de datos. Si se puede tolerar un retraso de codificación, un Coder puede detectar los cortes por adelantado y modificar dinámicamente la estructura del GOP de tal forma que una imagen I- se inserte para que coincida con el corte. En ese caso el corte es manejado con muy pocos datos extra. Las últimas imágenes B- antes del cuadro I- es casi seguro que usen la predicción adelantada. En algunas aplicaciones que no están en tiempo real, como el “masterizado” de DVD’s un Coder podría usar dos pasadas para codificar la entrada de video: una pasada para identificar las dificultades o áreas de entropía alta y crear una estrate-gia de codificación y una segunda pasada para comprimir en realidad la entrada de video.

2.13 Wavelets Todas las transformadas sufren de cierta incertidumbre ya que entre más exactamente se conozca el dominio de la frecuencia menos exacto será el dominio del tiempo (y viceversa). En la mayoría de las transformadas como la de Fourier de transporte o DFT (Discreet Fourier Transport) y la trans-formada discreta de coseno o DCT (Discreet Cosine Transform), la longitud del bloque es fija por lo que el tiempo y la resolución de frecuencia también serán fijos. Los coeficientes de frecuencia representan valores espaciados a la misma distancia en una escala lineal. Desafortunadamente, debido a que los sentidos humanos son logarítmicos, la escala uniforme del DFT y de la DCT nos da una resolución de frecuencia inadecuada en un extremo y un exceso de resolución en el otro.

► Figura 2-18 La transformada wavelet no es afectada por ese problema porque su reso-lución de frecuencia es una fracción fija de una octava y por tanto tendrá una característica logarítmica. Esto se hace cambiando la longitud del bloque como una función de la frecuencia. A medida que disminuye una frecuencia, el bloque se hará más largo. Así, una característica de la trans-formada wavelet es que todas las funciones de base contendrán el mismo número de ciclos y estos se escalarán simplemente a lo largo del eje del tiempo para buscar diferentes frecuencias. La Figura 2-18 contrasta el tamaño fijo de los bloques de DFT/DCT con el tamaño variable del wavelet. Los wavelets son especialmente útiles para la codificación de audio porque automáticamente se adaptan a los requerimientos en conflicto de la locali-zación exacta de los transitorios en tiempo y dan una valoración exacta de las frecuencias de los tonos estables. Para la codificación de video, las wavelets tienen la ventaja de producir señales de resolución escalable casi sin esfuerzo extra. En el video en movimiento, las ventajas de las wavelets son contrarrestadas por la dificul-tad de asignar vectores de movimiento a un bloque de tamaño variable pero la dificultad para codificar imágenes fijas o imágenes I- no es nada que deba preocupar. La codificación wavelet ha mostrado beneficios particulares para aplicaciones con muy baja relación de bits. Los artifacts generados por una cuantización excesiva de los coeficientes de la wavelet aparecen como “smearing,” y este es mucho menos objetable que la apariencia de bloques que provoca una cuantización excesiva de los coeficientes de DCT.



Sección 3 –Compresión de Audio La compresión de audio con pérdidas está completamente basada en las características de la audición humana las cuales deben ser consideradas antes de que cualquier descripción de la compresión sea posible. Sorpresi-vamente, la audición humana, en particular en estéreo, es en realidad más críticamente discriminatoria que la visión humana y consecuentemente la compresión de audio debe ser considerada con cuidado. Como con la compresión de video, la de audio requiere cierto número de diferentes niveles de complejidad de acuerdo al factor de compresión requerido.

3.1 El mecanismo de audición La audición comprende procesos físicos en el oído y los procesos nervio-so/mentales que combinados nos dan la impresión de sonido. La impresión que recibimos no es idéntica a la forma de onda acústica real presente en el canal auditivo debido a que cierta entropía se pierde. Los sistemas de compresión de audio que pierden solo la parte de la entropía que se perde-rá por el mismo mecanismo de audición producirán buenos resultados. El mecanismo físico de la audición está formado por el oído externo, el medio y el interno. El oído externo comprende el canal auditivo y el tímpa-no. Este convierte el sonido incidente en una vibración en una forma muy similar a como lo hace el diafragma de un micrófono. El oído interno trabaja censando las vibraciones transmitidas a través de un fluido. La impedancia del fluido es mucho mayor que la del aire y el oído medio actúa como un transformador de impedancias de acoplamiento que mejora la transferencia de potencia. La Figura 3-1 muestra que las vibraciones se transfieren al oído interno por medio del “estribo” que actúa en la ventana oval. Las vibraciones en el fluido en el oído viajan por el caracol, una cavidad espiral en el cráneo (se muestra desenrollado en la Figura 3-1 por claridad). La membrana basilar está estirada sobre el caracol. La membrana varía en masa y rigidez a lo largo de su longitud. Al final, cerca de la ventana oval, la membrana es rígida y ligera por lo que su frecuencia resonante es alta. En el extremo distante la membrana es pesada y suave y resuena a frecuencias bajas. El rango de las frecuencias resonantes disponibles determina el rango de frecuencia de la audición humana, la cual, en la mayoría de la gente es de 20 Hz a 15 KHz. Diferentes frecuencias a la entrada de sonido harán que diferentes áreas de la membrana vibre. Cada área tiene diferentes terminaciones nerviosas para permitir la discriminación de los tonos. La membrana basilar también tiene pequeños músculos controlados por los nervios que juntos actúan como una clase de sistema de retroalimentación positiva que mejora el factor Q de la resonancia.

El comportamiento resonante de la membrana basilar tiene un comporta-miento exactamente paralelo al de un analizador de transformadas. De acuerdo con la teoría de incertidumbre de las Transformadas, entre mas exactamente se conozca el dominio de la frecuencia de una señal menos exactamente se conocerá el dominio del tiempo. Consecuentemente, entre más capaz sea una transformada de discriminar entre dos frecuencias, menos capaz será discriminar entre el tiempo de dos eventos. La audición humana ha evolucionado con un cierto compromiso que balancea la incerti-dumbre de discriminación en el tiempo y la frecuencia; en el balance, nin-guna capacidad será perfecta. La discriminación imperfecta de la frecuencia provoca la incapacidad para separar frecuencias con muy poco espacio entre sí. Esta incapacidad es conocida como enmascaramiento de auditorio, definido como la sensibili-dad reducida a un sonido en presencia de otro. La Figura 3-2a (vea la siguiente página) muestra que el umbral de audición es una función de la frecuencia. La mayor sensibilidad estará, no sorpresi-vamente, en el rango del habla. En la presencia de un tono simple, el umbral es modificado como se ve en la Figura 3-2b. Note que el umbral se eleva para tonos de mayor frecuencia y hasta cierto punto a menor fre-cuencia. En la presencia de un espectro de entrada complejo, como la música, el umbral se eleva a casi a todas las frecuencias. Una consecuen-cia de este comportamiento es que el “hiss” de un cassette de audio analó-gico solo será audible durante los pasajes más tranquilos de la música. El “Compander” usa este principio amplificando las señales de audio de bajo nivel antes de la grabación o transmisión y luego las regresa con el nivel adecuado. ► Figura 3-1



► Figura 3-2a La discriminación imperfecta del oído es debida a su respuesta resonante. El factor Q es tal que un sonido dado tienen que estar presente por lo menos 1 milisegundo antes de que sea audible. Debido a esta respuesta lenta, el enmascaramiento aún puede llevarse a cabo cuando las dos señales involucradas no sean simultáneas. El enmascaramiento adelantado y retrasado ocurre cuando el sonido enmascara-dor continua enmascarando los sonidos a niveles más bajos antes y después de la duración real del sonido enmascarado- LA Figura 2-2 muestra este concepto. El enmascaramiento eleva el umbral de audición y los Compresores aprovechan este efecto elevando el ruido de piso lo que permite que la forma de onda de audio sea expresada con menos bits. El ruido de piso solo puede ser elevado a frecuen-cias a las cuales hay un enmascaramiento efectivo. Para maximizar el efecto del enmascaramiento es necesario dividir el espectro de audio en diferentes bandas de frecuencia para permitir la introducción de diferentes cantidades de “companding” y ruido en cada banda. ► Figura 3-3

► Figura 3-2b

3.2 Codificación sub banda La Figura 3-4 muestra un Compander divisor de banda. El filtro de división de banda es un juego de filtros de fase lineal de banda estrecha que se sobreponen entre sí y todos tienen el mismo ancho de banda. La salida de cada banda consiste de muestras que representan una forma de onda. En cada banda de frecuencia la entrada de audio es amplificada hasta un nivel máximo antes de la transmisión. Después de eso, cada nivel regresará a su valor correcto. El ruido captado en la transmisión es reducido en cada banda si la reducción de ruido es comparable con el umbral de audición. Se puede ver que se puede tolerar mayor ruido en algunas bandas debido al enmascaramiento. Consecuentemente, en cada banda, después del “companding”, es posible reducir la longitud de las palabras de las muestra. Esta técnica logra la compresión debido a que el ruido de cuantización introducido por la pérdida de resolución es enmascarado. ► Figura 3-4



► Figura 3-5 La Figura 3-5 muestra un Coder divisor de banda como el que se usa en MPEG capa 1. La entrada de audio digital es alimentada a un filtro de división de bandas que divide el espectro de la señal en un número deter-minado de bandas. En MPEG este número es 32. El eje del tiempo es dividido en bloques de igual longitud, de nuevo, en MPEG capa 1 hay 384 muestras de entrada, entonces habrán 12 muestras en cada una de las 32 bandas a la salida del filtro. Dentro de cada banda el nivel es amplificado por multiplicación para llevar el nivel al máximo. La ganancia requerida es constante para la duración del bloque y se transmite un factor de escala simple con cada bloque para cada banda con el fin de permitir la inversión del proceso en el Decoder. La salida del banco de filtros para MPEG capa 1 se analiza usando una FFT de 512 puntos para determinar el espectro de la señal de entrada. Este análisis conduce a un modelo de enmascaramiento que determina el grado de enmascaramiento que se puede esperar en cada banda. Entre más enmascaramiento esté disponible, menos exactas necesitarán ser las muestras en cada banda. La exactitud de la muestra es reducida recuanti-zando para reducir la longitud de las palabras. Esta reducción también es constante para cada palabra en una banda pero diferentes bandas pueden usar diferentes longitudes de palabra. Las longitudes de palabra necesitan ser transmitidas como un código de asignación de bits para cada banda para permitirle al Decoder deserializar adecuadamente el stream de bits.

► Figura 3-6

3.3 MPEG Capa 1 La Figura 3-6 muestra un stream de bits de audio en MPEG capa 1. Des-pués del patrón de sincronización y el encabezador hay códigos de asigna-ción de 32 bits de 4 bits cada uno. Esos códigos describen la longitud de la palabra de las muestras en cada sub banda. Después vienen los factores de escala 32 usados para el Companding de cada banda. Esos factores de escala determinan la ganancia necesaria en el Decoder para regresar el audio a su nivel correcto. Los factores de escala, a su vez, son seguidos por los datos de audio de cada banda.



► Figura 3-7 La Figura 3-7 muestra el Decoder de capa 1. El patrón de sincronización es detectado por el Generador de temporalización que deserializa la asignación de bits y los datos del factor de escala. Los datos de asignación de bits entonces permitirán la deserialización de las muestras de longitud variable. La recuantiza-ción es invertida y la compresión es invertida por los datos del factor de escala para regresar cada banda al nivel correcto. Esas 32 bandas separadas son entonces combinadas en un filtro combinador que produce la salida de audio.

3.4 MPEG Capa 2 La Figura 3-8 muestra que cuando se usa el Filtro de división de banda para controlar el modelo de enmascaramiento, el análisis espectral no es muy exacto ya que solo hay 32 bandas y la energía puede estar en cualquier parte de la banda. El ruido de piso no se puede elevar mucho porque, en el peor de los casos conocidos, el enmascaramiento no podría operar. Un análisis espectral más exacto permitiría un factor de compresión más alto. En MPEG capa 2, el análisis espectral es ejecutado por medio de un proceso separado. En este caso se usa una FFT (Fast Fourier Transform o Transformada rápida de Fourier) de 1024 puntos trabajando directamente desde la entrada para controlar el modelo de enmascaramiento. Para resolver las frecuencias más exactamente, la exten-sión de tiempo de la transformada se tiene que incrementar lo cual se hace elevando el tamaño del bloque a 1152 muestras. Mientras que el esquema de “companding” de bloque es el mismo que para la capa 1, no todos los factores de escala se transmiten ya que contienen cierto grado de redundancia en el material de programa real. El factor de escala de bloques sucesivos en la misma banda difieren por 2 dB, menos del 10% del tiempo y la ventaja es aprovechada por esta característica analizando juegos de tres factores de escala sucesivas. Cuando el contenido de la sub banda es aproximadamente constante (conocido como programa estacionario o quasi estacionario), solo un factor de escala de entre los tres es enviado. A medida que el contenido transitorio se incrementa en una sub banda determinada dos o tres factores de escala se enviarán. También se enviará un código de selección de factor de escala para permitirle al Decoder determinar que se va a enviar en cada sub banda. Esta técnica divide a la mitad en forma muy efectiva la relación de bits del factor de escala.

► Figura 3-8 3.5 Codificación de transformada Las capas 1 y 2 están basadas en filtros de división de banda en los que la señal sigue siendo representada como una forma de onda sin embargo, la capa 3 adopta una codificación de transformada similar a la que se usa para la codifica-ción de video. Como se mencionó antes, el oído ejecuta una clase de transfor-mada de frecuencia al sonido incidente y debido al factor Q de la membrana basilar, la respuesta no se puede incrementar o reducir rápidamente. Conse-cuentemente, si una forma de onda de audio es transformada al dominio de la frecuencia, no es necesario que los coeficientes se envíen muy frecuentemente. Este principio es la base de la codificación de transformada. Para factores de compresión más altos se pueden recuantizar los coeficientes haciéndolos menos exactos. Este proceso produce ruido que será colocado en frecuencias en las que el enmascaramiento sea mayor. Uno de los resultados del uso del Coder de transformada es que el espectro de entrada es conocido con exactitud por lo que se podrá crear un modelo de enmascaramiento preciso.



3.6 MPEG Capa 3 Este complejo nivel de codificación en realidad solo es requerido cuando se necesita el más alto nivel de compresión. Tiene un alto grado de cosas en común con la capa 2. Una transformada discreta de coseno se usa con 384 coeficientes de salida por bloque. Esta salida puede ser obtenida procesando directamente las muestras de entrada pero en un Coder de niveles múltiples es posible usar una transformada híbrida incorporando un filtraje a 32 bandas de las capas 1 y 2 como base. Si se hace esto, las 32 sub bandas del QMF (Qua-drature Mirror Filter o filtro de espejo de cuadratura) se procesarán además con un MDCT (Modified Discreet Cosine Transform, Transformada Discreta de Coseno modificada) para obtener 384 coeficientes de salida. Se usan dos tamaños de ventana para evitar el pre eco en los transitorios. La conmutación de ventana es ejecutada por el modelo psicoacústico. Se ha encontrado que el pre eco esta asociado con la entropía en el audio que se eleva por encima del valor promedio. Para obtener el factor de compresión más alto se usa la cuantización no uniforme de los coeficientes junto con la codifica-ción Huffman. Esta técnica asigna las longitudes de palabra más cortas a los valores de código más comunes.

3.7 Audio MPEG-2 Aunque originalmente fueron designados como niveles de audio MPEG 1, 2 y 3, los sistemas ahora son conocidos con más exactitud como MPEG-1 Nivel 1, etc. MPEG-2 define extensiones para el audio MPEG-1 y un nuevo sistema de codificación avanzado. MPEG-2 permite el uso del muestreo a relaciones más bajas que MPEG-1. Esto no es exactamente compatible con lo anterior pero solo requiere tablas adiciona-les en un Decoder MPEG-1 para la interoperatibilidad. El audio MPEG-2 BC (compatible con el anterior) proporciona 5.1 canales (5 canales de ancho de banda complete más un canal de efectos de baja frecuen-cia y bajo ancho de banda), MPEG-2 BC tiene un stream de bits MPEG-1 (2 canales) en su núcleo y adicio-na las extensiones de canales múltiples en un formato que será ignorado por un Decoder MPEG-1. MPEG-2 AAC (Advanced Audio Coding, Codificación avanzada de audio) es un sistema más sofisticado con bancos de filtros de mayor resolución y herramien-tas de codificación adicionales. Ofrece una eficiencia de codificación significati-vamente mayor pero no es compatible con lo anterior.

3.8 MPEG-4 Audio La codificación MPEG-4 está basada en objetos (vea la sección 4.4.2). El audio en MPEG-4 puede representar sonidos naturales o sintéticos. Para la codifica-ción de audio natural, el kit de herramientas de MPEG-4 incluye el MPEG-2 AAC así como una variedad de otras herramientas. Estas incluyen la codificación paramétrica para relaciones de bit muy bajas y una técnica conocida como codificación predictiva lineal excitada por código o CELP (Code Excited Linear Predictive) para la codificación de la voz con relaciones de bits de rango medio. Se respaldan varias formas de escalabilidad incluyendo la escalabilidad del stream de bits que puede ser aplicada en puntos determinados en el sistema de transmisión. El uso de la codificación de objetos permite hacer elecciones en el punto de decodificación. Por ejemplo, se puede transmitir un concierto como dos objetos: orquesta y solista. La decodificación normal presentará el trabajo com-pleto pero un instrumentista puede decodificar solo el objeto “orquesta” y ejecu-tar la parte del solista “en vivo”. Otras aproximaciones similares pueden permitir la codificación de programas de tal manera que el auditorio pueda seleccionar un modo de “mix minus” para eliminar los comentarios de, digamos, un evento deportivo. Las capacidades de audio sintético de MPEG-4 se usarán, sin duda, en forma extensa en el futuro. Estas incluyen las capacidades de “texto a voz” y técnicas “controladas por el resultado” en los que la música es sintetizada con instrumen-tos descargados usando el lenguaje estructurado de orquesta de audio o SAOL (Structured Audio Orchestra Language).



3.9 AC-3 La técnica de codificación de audio AC-3, inventada por los Laboratorios Dolby se usa con el sistema ATSC en lugar de uno de los esquemas de codificación de audio en MPEG. Está documentado como Norma ATSC a/52. Subsecuen-temente, el AC-3 fue adoptado como una componente opcional de la DVB y por el sistema de Motorola Digicypher II. AC-3 es un sistema basado en transforma-das que obtiene una ganancia de codificación recuantizando los coeficientes de la frecuencia. La entrada PCM de un Coder AC-3 es dividida en bloques con ventanas que se sobreponen como se muestra en la Figura 3-9. Esos bloques contienen 512 muestras cada uno pero debido a la sobreposición completa hay una redundan-cia del 100%. Después de la transformada hay 512 coeficientes en cada bloque pero debido a la redundancia, esos coeficientes se pueden reducir a 256 coefi-cientes usando una técnica llamada cancelación de aliasing en el dominio del tiempo o TDAC (Time Domain Aliasing Cancellation. La forma de onda de la entrada se analiza y si hay un transitorio significativo en la segunda mitad del bloque, la forma de onda se dividirá en dos para evitar el pre eco. En este caso, el número de coeficientes permanece igual, pero la resolución de la frecuencia se dividirá a la mitad y la resolución temporal se duplicará. Se establecerá una bandera en el stream de bits para indicarle al Decoder que se hizo esto. Los coeficientes son sacados en notación de punto flotante como una mantisa y un exponente. La representación es el equivalente binario de la notación científi-ca. Los exponentes son efectivamente factores de escalado. El juego de expo-nentes en un bloque produce un análisis espectral de la entrada con una exacti-tud finita en una escala logarítmica llamada “envolvente espectral”. El análisis espectral es la entrada al modelo de enmascaramiento que determina el grado al cual el ruido puede elevarse en cada frecuencia.

► Figura 3-9 El modelo de enmascaramiento controla el proceso de recuantización que reduce la exactitud de cada coeficiente redondeando la mantisa. Una proporción significativa de los datos transmitidos consiste de valores de mantisa. Los exponentes también son transmitidos pero no directamente ya que contie-nen redundancias que se pueden explotar. Dentro de un bloque solo el primer exponente (menor frecuencia) es transmitido en forma absoluta. Los exponentes restantes se transmiten en forma diferencial y el Decoder adiciona la diferencia al valor previo. Donde el audio de entrada tenga un espectro suave, los expo-nentes en muchas bandas de frecuencia pueden ser los mismos. Los exponen-tes se pueden agrupar en juegos de dos o cuatro con banderas que describan lo que se ha hecho, Juegos de 6 bloques se ensamblan en un cuadro de sincronía AC-3. El primer bloque del cuadro siempre tiene todos los datos de exponentes pero en casos de señales estacionarias, los últimos bloques en el marco pueden usar los mismos exponentes.



Sección 4 – Las normas MPEG Las secciones 2 y 3 presentaron las tecnologías de compresión de audio y video y muchas de las herramientas usadas en las normas MPEG. Esta sección examina la historia y estructura de MPEG y la evolución de varias de las normas MPEG.

4.1 ¿Que es MPEG? MPEG es el Grupo de expertos de imágenes en movimiento, un comité al servicio de la Organización Internacional de Normas o ISO (International Stan-dards Organization) y la Comisión Electrotécnica Internacional o IEC (Internatio-nal Electrotechnical Commission). La IEC maneja la normalización internacional para las tecnologías eléctrica y electrónica; ISO virtualmente maneja todo lo demás. Al inicio de la edad de la tecnología de la información ISO e IEC forma-ron un comité técnico (JTC1) para que se ocupara de las cosas relacionadas con la IT. El JTC1 tiene un número de grupos de trabajo, incluyendo JPEG (Joint Photographic Experts Group, Grupo de expertos en fotografía) y WG11 que es MPEG. El comité fue formado en 1988 bajo el liderazgo del convocante, Dr. Leonardo Chiariglione de Italia. La concurrencia a las reuniones de MPEG, normalmente mantenidas 4 veces al año ha crecido de unos 15 delegados en 1988 a unos 300 en 2002. Establecieron un precedente envidiable de genera-ción de normas que lograron una adopción extensa, MPEG-1, MPEG-2 y la norma de compresión de audio MP3 (MPEG-1 Audio, capa 3). Esta reputación fue empañada de alguna forma por MPEG-4, no debido a deficiencias en la norma sino como resultado del largo retraso para publicar los términos de la licencia y la fuerte reacción adversa a los primeros términos que eventualmente se publicaron a principios de 2002. Se debe hacer notar que MPEG por si misma no juega ningún papel para el licenciamiento. Como comité de ISO e IEC, requiere que las tecnologías inclui-das en sus normas sean licenciables bajo “términos razonables y no discrimina-torios” pero no hay una definición aceptada de “razonable”. El licenciamiento es responsabilidad de quienes poseen las patentes relevantes y esto típicamente implica muchas organizaciones por todo el mundo que han contribuido a la investigación y el desarrollo y quieren ver alguna recompensa. Para MPEG-2, quienes tienen la patente se agruparon y formaron MPEG-LA (Grupo MPEG para autorizar licencias). Todas las patentes esenciales son certificadas por este grupo y son licenciadas como un bloque a cualquier organi-zación que quiera implementar las normas. Esto funcionó bien para MPEG-2, pero como se mencionó antes, se están experimentando mayores dificultades con MPEG-4 y mucha gente responsabiliza a los retrasos en la publicación de los términos de la licencia por la actual falta de éxito comercial de MPEG-4 (Esto, por supuesto, puede cambiar. El foro industrial de MPEG-4 está trabajan-do muy fuerte para encontrar soluciones aceptables para quienes ostentan las patentes y los usuarios potenciales y revisando las propuestas aparecidas a mediados del 2002 que son más factibles de ser aceptadas más fácilmente).

4.2 MPEG-1 El sistema MPEG-1, ISO/IEC 11172, es la primera norma de compresión para imágenes en movimiento y fue desarrollada entre 1988 y 1992. Usa transforma-das de DCT, cuantización de coeficientes y codificación de longitud variable en una forma similar a JPEG pero también incluye la compensación de movimiento para la compresión temporal. Poniéndola en tres partes tendríamos: ► Sistema ISO/IEC 11172-1, la estructura múltiplex

► ISO/IEC 11172-2, codificación de video

► ISO/IEC 11172-3, codificación de audio

MPEG-1 representó un logro técnico excepcional. Fue diseñada para comprimir Streams de imagen con tamaños de imagen SIF, 352x288 (25-Hz PAL) o 352x240 (30Hz NTSC) y el audio asociado a, aproximadamente 1.5 Mbits/s de relación de datos comprimidos total. Esta relación es adecuada para el transpor-te en circuitos de datos T1 y para la reproducción desde CD-ROM; corresponde aproximadamente a la resolución de una grabadora de video de consumidor. Una medición de este logro puede verse comparando los números de un CD de audio. Un CD de audio normal que transporta dos canales de audio con una resolución de 16 bits, con una relación de muestreo de 44.1 kHz, tiene una relación de transferencia de datos de hasta 1.5 Mbit/s. ¡MPEG-1 comprime el audio y video de tal forma que ambos puedan ser trans-mitidos con la misma relación de datos! El formato CIF es un compromiso entre los formatos Europeo y Americano SIF (Source Input Format, Formato de fuente de entrada): resolución espacial para 625 SIF (352x288) y Resolución temporal 525 SIF (29.97 Hz). Esta es la base para la videoconferencia. MPEG-1 puede ser diseñada para imágenes CIF y no tiene herramientas para manejar imágenes entrelazadas por lo que tiene un impacto obviamente peque-ño en el mundo del broadcast de televisión. Antes de dejar el MPEG-1, es importante hacer notar lo que en realidad incluye la norma y como se logra la interoperatibilidad. La norma define un juego de herramientas, la sintaxis del stream de bits y la operación del Decoder. No define la operación del Encoder – cualquier dispositivo que produce un stream de bits sintácticamente válido que pueda ser decodificado por un Decoder que cumpla con esta norma será un Encoder MPEG válido. Además, no define la calidad de la imagen ni la calidad de la codificación. Esto permite la evolución de la tecnología de codificación sin cambiar la norma y sin condenar a la obsoles-cencia los Decoders existentes. Este modelo es usado en todas las normas MPEG. El éxito de esta estrategia es obvia, aunque MPEG-2 se usa para video, MPEG-1 capa 2 audio aún se usa como sistema de compresión principal para audio en los sistemas actuales de transmisión DVB.



4.3 MPEG-2 MPEG-1 fue congelada (es decir, los cambios subsiguientes solo se permitieron a nivel editorial) en 1991. En el mismo año el proceso de MPEG-2 empezó y eventualmente se convirtió en una norma en 1994. Las metas iniciales fueron simples; había la necesidad de una norma que pudiera acomodar video con calidad de broadcast. Esto requería la codificación de imágenes de definición estándar a “tamaño completo” (704x480 a 29.97 Hz y 704x576 a 25 Hz) y la capacidad de codificar video entrelazado eficientemente. En muchas formas MPEG-2 representa la “siguiente era” de MPEG. La mayor flexibilidad de MPEG-2 combinada con la disponibilidad incrementada de circui-tos integrados con gran escala de integración implicó que MPEG-2 pudiera usarse en un vasto número de aplicaciones. El éxito de MPEG-2 se destaca mejor con la “muerte” de MPEG-3 diseñada para televisión de alta definición. MPEG-3 pronto fue abandonada cuando quedó claro que MPEG-2 podía aco-modar esta aplicación con facilidad. MPEG-2 es, por supuesto, la base tanto para las normas de broadcast ATSC y DVB como del sistema de compresión usado por el DVD. También se permitió que MPEG-2 fuera un blanco móvil. Con el uso de los perfiles y niveles, que se discutirán más abajo fue posible completar la norma para una aplicación pero luego moverse para acomodar aplicaciones más demandantes en una forma evolutiva. Los trabajos para extender MPEG-2 continúan en 2002. MPEG-2 es documentada como ISO/IEC 13818, actualmente en 10 partes. Las partes más importantes de esta norma son: ► ISO/IEC 13818-1 Sistemas (transporte y streams de programa), PES, T-STD

modelo de Buffer y las tablas PSI básicas: CAT, PAT, PMT y NIT.

► ISO/IEC 13818-2 codificación de video

► ISO/IEC 13818-3 codificación de audio

► ISO/IEC 13818-4 Prueba y conformidad MPEG

► ISO/IEC 13818-6 transmisión de datos y DSMCC.

Uno de los logros principales de MPEG-2 definido en 13818-1, el stream de transporte, se describe en la Sección 8. La flexibilidad y robustez de este diseño ha permitido que sea utilizado por muchas aplicaciones incluyendo el transporte de datos de MPEG-4 y MPEG-7. Nota: Los streams de transporte de DVB y ATSC llevan PES de video y audio dentro de agrupaciones de “programa” que son completamente diferentes a los “streams de programa” (estos son usados en DVD y CD), Los streams de transporte MPEG normalmente son de relaciones de bits cons-tantes pero los streams de programa normalmente son de relaciones de bit variables.

4.3.1 Perfiles y niveles en MPEG-2 Con ciertas excepciones menores, MPEG-1 fue diseñada para una tarea; la codificación de imágenes de tamaño fijo y el audio asociado a una relación de bits conocida de 1.5 Mbits/seg. Las herramientas y sintaxis de MPEG-1 pueden y se han usado para otros propósitos, pero esos usos están fuera de la norma y requieren de Encoders y Decoders de propietario, Solo hay un tipo de Decoder que cumple con la norma MPEG-1. En sus inicios había una meta similar para MPEG-2. Esta norma fue diseñada para codificar imágenes para broadcast y sonido, nominalmente los sistemas de televisión entrelazados de 525/60 y 625/50; sin embargo, a medida que progre-saba el diseño se hizo aparente que las herramientas que se estaban desarro-llando eran capaces de manejar muchos tamaños de imagen y un amplio rango de relaciones de bit. Además, se desarrollaron herramientas más complejas para sistemas de codificación escalables. Esto implicó que en la práctica no podría haber un Decoder MPEG-2 sencillo. Si un Decoder que cumpliera con la norma tenía que ser capaz de manejar streams de bit de alta velocidad codifica-dos usando todas las herramientas posibles ya no podría ser un Decoder eco-nómico para aplicaciones estándar. Como ejemplo simple, un dispositivo capaz de decodificar señales de alta definición a, digamos, 20 Mbits/seg, sería subs-tancialmente más caro que uno limitado a las señales de definición estándar de unos 5 Mbits/seg. Sería una norma muy pobre la que requiriera el uso de un dispositivo caro para una aplicación simple. MPEG diseñó una estructura bidimensional de perfiles y niveles para clasificar los streams de bits y Decoders. Los perfiles definen las herramientas que se pueden usar, Por ejemplo, la codificación bidireccional (cuadros B-) pueden ser usados en el perfil principal pero no en el perfil simple. Los niveles relacionan solo la escala. Un Decoder de alto nivel debe ser capaz de recibir un stream de bits más rápido y debe tener más Buffer de Decoder y Almacenes de cuadro más grandes que un Decoder de nivel principal; sin embargo, el perfil principal a nivel alto (MP@HL) y el perfil principal a nivel principal (MP@ML) usan exacta-mente las mismas herramientas de codificación/decodificación y elementos de sintaxis. La Figura 4-1 muestra el pareado de perfiles y niveles que son definidos por MPEG-2 (Perfiles en el eje horizontal, Niveles en el vertical). Hay que hacer notar que no todas las combinaciones son válidas; solo los pares completados están definidos en la norma. Es un requerimiento de conformidad con la norma que un Decoder en cualquier Perfil/Nivel debe ser capaz de decodificar los perfiles y niveles más bajos. Por ejemplo, un Decoder MP@ML debe ser capaz de decodificar streams de bit de perfil principal a nivel bajo (MP@LL) y de perfil simple a nivel principal (SP@ML).



► Figura 4-1 El perfil simple no respalda la codificación bidireccional y por tanto solo las imágenes I- y P- formarán la salida. Esto reduce el retraso de codificación y decodificación y permite un hardware más simple. El perfil simple solo ha sido definido a nivel principal. El perfil principal está diseñado para una gran cantidad de usos. El nivel principal usa una entrada de baja resolución que solo tiene 352 pixeles por línea. La mayoría de las aplicaciones de broadcast requerirán el subjuego de MPEG MP@ML que respalda la SDTV (Standard Definition TV, Televisión de definición estándar). El nivel high-1440 es un esquema de alta definición que duplica la definición en comparación con el nivel principal, El nivel alto no solo duplica la resolución sino que mantiene esa relación para el formato 16:9 incrementando el número de muestras horizontales de 1440 a 1920.

En los sistemas de compresión que usan la transformada espacial y la recuanti-zación es posible producir señales escalables. Un proceso escalable es aquél en el que la entrada da como resultado una señal principal y una señal “auxiliar”. La señal principal ser puede decodificada sola para dar una imagen de una cierta calidad pero si la información de la señal auxiliar se adiciona se puede mejorar algún aspecto de calidad. Por ejemplo, un Coder MPEG convencional, recuantizando fuertemente los coeficientes, puede codificar una imagen con resultados moderados de propor-ción señal a ruido. Sin embargo, si esa imagen es decodificada localmente y substraída píxel a píxel de la original, se tendrá como resultado una imagen con ruido de cuantización. Esa imagen puede ser comprimida y transmitida como señal auxiliar. Un Decoder simple solo decodificará el stream de bits principal ruidoso pero un Decoder más complejo puede decodificar ambos streams de bits y combinarlos para producir una imagen con bajo ruido. Este es el principio de la escalabilidad de SNR (Signal-to-Noise Ratio. Relación señal a ruido).



Como alternativa, codificando solo las frecuencias espaciales más bajas en una imagen de HDTV podemos producir un stream de bits principal que un receptor de SDTV puede decodificar. Si la imagen de menor definición es decodificada localmente y substraída de la imagen original tendremos como resultado una imagen de definición mejorada. Esta imagen puede ser codificada en una señal auxiliar. Un Decoder adecuado puede combinar las señales principal y auxiliar para recrear la imagen de HDTV. Este es el principio de la escalabilidad espa-cial. El perfil alto respalda tanto la SNR y la escalabilidad espacial así como permite la opción de muestreo en 4:2:2. El perfil 4:2:2 ha sido desarrollado para mejorar la compatibilidad con el equipo de producción digital. Este perfil permite la operación a 4:2:2 sin requerir la complejidad adicional del uso del perfil alto. Por ejemplo, un Decoder HP@ML debe soportar la escalabilidad de SNR que no es un requerimiento para la producción. El perfil 4:2:2 tiene la misma libertad de estructura del GOP que los otros perfiles pero en la practica se usa comúnmente con GOPs cortos haciendo que sea más sencilla la edición. La operación en 4:2:2 requiere una relación de bits mayor que 4:2:0 y el uso de GOPs cortos requiere una relación de bits más alta y pareja para una calidad dada. El concepto de los perfiles y niveles es otro de los desarrollos de MPEG-2 que ha probado ser robusto y extensible; MPEG-4 usa un arreglo mucho más com-plejo de perfiles y niveles que discutiremos más adelante.

4.4 MPEG-4 La normalización internacional es un proceso lento y los avances tecnológicos que frecuentemente ocurren pueden incorporarse a una norma que se esta desarrollando. Frecuentemente esto es deseable pero el mejoramiento continuo puede significar que la norma nunca llega a terminarse y ser usual. Para asegu-rar que una norma eventualmente se termine hay reglas estrictas que prohíben los cambios sustantivos después de cierto punto del proceso de normalización, Así, para el momento en el que la norma se adopta oficialmente frecuentemente hay una acumulación de mejoramientos deseados y extensiones. Esto pasó con MPEG-2. Como se discutió antes, MPEG-3 se comenzó y se abandonó; enton-ces el siguiente proyecto se convirtió en MPEG-4. Actualmente hay dos versio-nes completas de MPEG-4 y se sigue trabajando en otras extensiones. Al principio el enfoque principal de MPEG-fue la codificación de video y audio a relaciones muy bajas. De hecho, la norma fue explícitamente optimizada para tres rangos de relaciones de bit:: ► Por debajo de 64 kbits/s.

► 64 a 384 kbits/s.

► 384 kbits/s a 4 Mbits/s

El desempeño a relaciones de bit bajas permaneció como objetivo principal y algunas ideas muy creativas contribuyeron para ese fin. También se prestó mucha atención a la resistencia a los errores haciendo que MPEG-4 sea muy útil para su uso en ambientes propensos a errores como la transmisión a dispo-sitivos personales manuales; sin embargo, otros perfiles y errores usan relacio-nes de bits de hasta 38.4 Mbits/s y aún se está trabajando en perfiles y niveles con calidad de estudio usando relaciones de datos de hasta 1.2 Gbits/s. Más importante, MPEG-4 se ha convertido en mucho más que otro sistema de compresión, ha evolucionado hacia un nuevo concepto de codificación multime-dia con poderosas herramientas para interactividad y un vasto rango de aplica-ciones. Aún la “introducción” oficial de esta norma se extiende por 67 páginas, por lo que aquí solo es posible dar una breve introducción al sistema.

4.4.1 Documentos de la norma MPEG-4 Las partes principales de las normas MPEG-4 son: ► ISO/IEC 14496-1 Sistemas

► ISO/IEC 14496-2 Visual

► ISO/IEC 14496-3 Audio

► ISO/IEC 14496-4 Pruebas de conformidad

► ISO/IEC 14496-6 Marco de trabajo para la integración o DMIF (Delivery Multimedia Integration Framework)

4.4.2 Codificación de objetos La desviación más significativa de los sistemas de transmisión convencionales es el concepto de los objetos. Diferentes partes de la escena final se pueden codificar y transmitir por separado como objetos de audio y de video que hay que juntar o componer con el Decoder. Diferentes tipos de objeto pueden ser codificados independientemente con las herramientas más adecuadas para el trabajo. Los objetos pueden generarse independientemente o se puede analizar una escena por separado, por ejemplo, los objetos del background o del fore-ground. En una demostración muy interesante, la cobertura de video de un partido de football soccer fue procesada para separar la pelota del resto de la escena. El background (la escena sin la pelota) se transmitió como un “teaser” para atraer audiencia al evento en “pay-per-view”: cualquier persona podía ver a los jugadores en el campo pero solo aquellos que pagaron podían ver el balón.



► Figura 4-2 La aproximación orientada a objetos nos lleva a tres características clave de los streams MPEG-4: ► Los objetos múltiples pueden ser codificados usando diferentes técnicas y

“componerse” en el Decoder

► Los objetos pueden ser de origen natural, como las escenas de una cámara

o sintéticas como el texto.

► Las instrucciones en el stream de bits y/o la elección del usuario pueden

habilitar muchas presentaciones diferentes del mismo stream de bits.

El sistema generalizado para la codificación de objetos en MPEG-4 se muestra en la Figura 4-2. Este diagrama también enfatiza las oportunidades de interac-ción con el usuario dentro de los sistemas MPEG-4 – una función muy podero-sa, particularmente para los diseñadores de juegos de video.

Esas capacidades no tienen que ser usadas, MPEG-4 proporciona la codifica-ción tradicional de audio y video y mejora MPEG-2 al ofrecer una eficiencia mejorada y resistencia a los errores; sin embargo, la verdadera potencia de MPEG-4 viene de la arquitectura descrita anteriormente, La codificación de objetos de forma independiente ofrece un número de ventajas. Cada objeto puede ser codificado en la forma más eficiente y se pueden usar diferentes relaciones de escalamiento espacial o temporal (ver 4.4.3) como sea apropiado.



► Figura 4-3 4.4.3 Codificación de audio y video Muchas de las herramientas de codificación de video en MPEG-4 son similares a las de MPEG-2 pero mejoradas por el mejor uso de la codificación predictiva y una codificación de entropía más eficiente; sin embargo, la aplicación de las herramientas puede diferir significativamente de las primeras normas. MPEG-4 codifica objetos de video. En el modelo más simple un video es codifi-cado en una forma muy similar a MPEG-2 pero es descrito como un objeto de video simple con una forma rectangular. La representación de la imagen es conocida como codificación de textura. Donde haya más de un objeto de video, algunos podrían tener formas irregulares y generalmente serán más pequeños que un objeto en background de pantalla completa. Esto significa que solo el

área activa del objeto necesitará ser codificada pero la forma y posición también puede ser representada. La norma incluye herramientas para la codificación de la forma de objetos rectangulares e irregulares en sus representaciones ya sea binarias o en escala de grises (similar a un canal alpha). Este concepto se muestra en la Figura 4-3. En forma similar, MPEG-4 usa herramientas similares a las de MPEG-1 y MPEG-2 para la codificación de audio en vivo y AAC ofrece una mayor eficien-cia. Múltiples “objetos” de audio pueden codificarse por separado y “componer-se” en el Decoder. Como con el video, los objetos de audio pueden ser naturales o sintéticos.



► Figura 4-4 4.4.4 Ecalabilidad En el contexto de la compresión de media la escalabilidad implica la habilidad de distribuir contenido a más de un nivel de calidad dentro del mismo stream de bits. Tanto MPEG-2 como MPEG-4 proporcionan perfiles escalables usando un modelo convencional; el Encoder genera una capa de base y una o mas capas de mejoramiento como se muestra en la Figura 4-4. La(s) capa(s) de mejora-

miento pueden ser descartadas para la transmisión o decodificación si no se dispone de los recursos suficientes. Esta aproximación funciona pero todas las decisiones acerca de los niveles de calidad tienen que hacerse en el momento de la codificación y en la práctica el número de capas de mejoramiento están severamente limitadas (usualmente a una).



► Figura 4-5 Versiones posteriores de MPEG-4 incluyen el perfil de escalabilidad de grano fino o FGS (Fine Grain Scalability). Esta técnica genera un stream de bits sim-ples que representa el nivel de calidad más alto pero que permite que las ver-siones de menor calidad se puedan extraer en “downstream”. El FGS usa la codificación de bit plano mostrado en concepto en la Figura 4-5. Los coeficientes cuantizados son “divididos”, un bit a la vez, comenzando con el bit más significa-tivo. Esto proporciona una representación “tosca” del coeficiente (s) más gran-de(s) (y significativo(s). Otras divisiones subsecuentes proporcionan representa-ciones más exactas de esos coeficientes más significativos y aproximaciones toscas de los siguientes más significativos y así sucesivamente. El escalamiento espacial, incluyendo al FGS, puede ser combinado con el escalamiento temporal que permita la transmisión y/o decodificación de relacio-nes de cuadro más bajas cuando los recursos sean limitados. Como se mencio-nó antes, los objetos pueden ser escalados en forma diferente; podría ser apropiado que retengan toda la resolución temporal para un objeto importante en el foreground pero actualizar el background como una relación menor.

4.4.5 Otros aspectos de MPEG-4 MPEG-4 es enorme y los comentarios que se acaban de hacer solo tocan unos pocos de los muchos aspectos de la norma. Hay perfiles de estudio para codifi-cación de alta calidad, la cual, junto con la codificación de objetos permitirá el almacenamiento estructurado de todos los elementos separados de un video compuesto. Extensiones adicionales de MPEG-4 podrían proporcionar aún niveles de calidad adecuados para cine digital. La Figura 4-6 muestra los perfiles de MPEG-4 definidos actualmente. (Note que en este diagrama solo se mues-tran los perfiles; generalmente los niveles múltiples son definidos para cada perfil) Algunos de los tipos de objetos definidos dentro de MPEG-4 son interesantes. Un ejemplo es un “sprite”. Un “Sprite” es un objeto estático en el background, generalmente más grande que la pantalla o el dispositivo de despliegue. Por ejemplo, la acción de un juego de video puede tener lugar al frente de una escena en el background. Si se usa un “sprite” un background estático grande puede ser transmitido una vez y a medida que la acción del juego proceda la parte apropiada del background se verá de acuerdo con el movimiento del puerto de vista.



► Figura 4-6 MPEG-4 define los perfiles de animación tanto faciales como del cuerpo. En cada caso se pude usar una cara o cuerpo preestablecida y se enviarán instruc-ciones para animar este objeto. Alternativamente, el objeto preestablecido puede ser modificado por el stream de bits; por ejemplo, una cara específica puede se transmitida y luego animada. Las instrucciones sofisticadas de anima-ción relacionadas con el lenguaje permitirán que una cara almacenada “lea” texto en muchos lenguajes. Algunas personas describen MPEG-4 como la norma para juegos de video y ciertamente muchas de las implementaciones son muy útiles para esta industria; sin embargo, aún una examinación superficial de la norma revela tal riqueza de capacidades y profundidad en cada aspecto que las aplicaciones potenciales no tienen fin.

4.4.6 El futuro de MPEG-4 Como se describió anteriormente, MPEG-4 es un juego de normas de amplio rango con una oferta muy rica de capacidades para muchas aplicaciones. Esta es la teoría, en la práctica MPEG-4 puede mostrar pocos éxitos. En particular muchos observadores esperaban que MPEG-4 rápidamente se convirtiera en el mecanismo de codificación dominante para el material audio-visual transmitido por Internet y que reemplazara las varias propuestas de codecs de propietario que se usan actualmente. Esto no ha pasado ni tampoco es probable que pase en el futuro próximo. Hay dos razones para esta falla.



La primera es tecnología y el desempeño resultante MPEG-4 usa tecnología de compresión de video basada en la norma H.26x desarrollada por la ITU fechada a principios de los 90s. La distribución de audio y video por medio de Internet es un negocio altamente competitivo y los tres contendientes principales: Apple, Microsoft y RealNetworks, han implementado esquemas de codificación de propietario que superan al Codec actual de MPEG-4. La otra razón de la falla (a la fecha) de MPEG-4 es la situación del licenciamien-to de la patente. Hasta principios del 2002, las compañías que querían imple-mentar MPEG-4 no sabían que regalías tenían que pagar a los poseedores de la patente. El esquema de licenciamiento propuesto para los niveles básicos de MPEG-4 ya se publicó ahora y encontró una fuerte reacción adversa de parte de la industria. Los términos del licenciamiento para los niveles más sofisticados aún son desconocidos. Ciertamente la oferta inicial de los términos de licencia-miento no ha hecho nada por incrementar la implementación global de la norma. Sin embargo hay esperanzas para el futuro. Un esfuerzo conjunto de ITU y MPEG, conocido como unión del grupo de video o JVT (Joint Video Team) está trabajando en un Codec conocido como H.26L. Citando al ITU, “El diseño del H.26L es un Coder de transformada híbrido de movimiento compensado basado en bloques - similar al sprite pero diferente en muchas cosas específicas rela-cionadas con los diseños anteriores… El H.26L incrementa significativamente el número de tamaños de bloque disponibles y el número de imágenes de referen-cia disponibles para hacer la estimación de movimiento (1/8 de píxel en algunas implementaciones) y esta basado en un tamaño de bloque principal de 4x4 en lugar del 8x8 utilizado en la mayoría de sistemas MPEG. Se espera que el H.26L muestre mejoramientos substanciales en eficiencia de codificación y la meta de los participantes es que el nivel de base, adecuado para el streaming de Internet esté libre de regalías. La primera etapa del trabajo del JVT se espera que esté completo en 2002 y se publique como MPEG-4 Parte 10.

4.5 MPEG-7 Debido a que se canceló MPEG-3 la secuencia real de las normas fue MPEG-1, MPEG-2 y MPEG-4. Algunos participantes del comité querían que la nueva norma fuera MPEG-5; otros fueron atraídos por la naturaleza binaria de la secuencia y preferían MPEG-8. Finalmente, se concluyó que cualquier secuen-cia simple fallaría en señalar la diferencia fundamental del trabajo de MPEG-1 a MPEG-4 y se eligió MPEG-7. MPEG-7 no es tanto acerca de la compresión sino acerca de la metadata, también conocida como “bits acerca de los bits”. La metadata es información digital que describe el contenido de otros datos digitales. En el habla moderna, el material de programa o contenido, la imagen en sí, los objetos de video, audio o datos que forman la información son conocidos como datos de esencia. La metadata le dice al mundo todo lo que necesita saber acerca de lo que está en la esencia.

Cualquiera que se ha involucrado con el almacenamiento de información ya sean cintas de video, libros, música, lo que sea, conoce la importancia y la dificultad de catalogar e indexar con exactitud. La información almacenada solo es útil si se conoce su existencia y si puede ser recuperada de forma oportuna cuando sea necesario. Este problema siempre ha estado con nosotros y ha sido atacado en el dominio analógico por una combinación de etiquetas, catálogos, tarjetas de índice, etc. Más recientemente, la industria del cómputo nos ha dado bases de datos relacionales eficientes y efectivas en costo que permiten que poderosos motores de búsqueda accedan a información almacenada en formas notables. Asumiendo que la información esté presente en una forma en que el motor de búsqueda pueda usarla. Aquí esta el problema verdadero. El mundo está generando nuevos conte-nidos de media con una frecuencia enorme y siempre creciente. Con el incremento en cantidad y la disminución de costos de la media de almace-namiento digital, más y más de ese contenido se puede almacenar. Las redes locales y de área ancha pueden hacer que el contenido sea accesible y distribuible si se le puede encontrar. Los motores de búsqueda pueden hallar lo que quieran y las bases de datos pueden encadenarse al material mismo pero necesitamos tener toda la información de indexación necesaria dentro de la base de datos en una forma útil para el motor de búsqueda. Debemos suponer, gracias al conocimiento de las normas anteriores, que el comité MPEG no se involucraría en exceso con mecanismos para generar datos. MPEG, acertadamente toma como propio el punto de vista de que si crea una estructura normalizada y hay la necesidad de mercado, los huecos tecnoló-gicos serán llenados. En normas MPEG previas la sintaxis y el Decoder fueron especificados por la norma. En MPEG-7 solo la sintaxis está normalizada como se muestra en la Figura 4-7. La generación de la metadata no está especificada como lo son las aplicaciones que pueden utilizarla. MPEG-7 especifica como se debe expresar la metadata. Esto significa que los campos deben ir a una base de datos como se especifica y cualquiera que diseñe un motor de búsqueda sabe que elementos descriptivos pueden estar presentes y como serán codifi-cados. MPEG-7 define una estructura de descriptores y esquemas de descripción que pueden caracterizar casi cualquier cosa. En teoría al menos, los elementos primitivos como los histogramas de color y las formas pueden ser combinados para representar entidades complejas como caras individuales. Es posible indexar automáticamente material de tal forma que la base de datos pueda ser consultada por escenas que muestren, por ejemplo, al Presidente Clinton y al presidente Greenspan de la Reserva Federal de U.S. juntos. Las construcciones no están confinadas a imágenes. Debe ser posible usar una muestra de voz para buscar por grabaciones o imágenes de Pavarotti o reproducir unas pocas notas en un teclado para encontrar las coincidencias o melodías similares.



► Figura 4-7 El rápido avance de los sistemas de almacenamiento y trabajo en red permitirán el acceso a vastas cantidades de contenido digital. A medida que avanza la tecnolo-gía para satisfacer las necesidades de MPEG-7, seremos capaces de indexar y recuperar ítems en formas inimaginables tan solo hace unos pocos años. Entonces tendremos la necesidad de un sistema para controlar el acceso, privacidad y transacciones comerciales asociadas con este contenido. Este es el punto hacia donde está orientado MPEG-21.

4.6 MPEG-21 MPEG-21, de nuevo, difiere en clase de los trabajos anteriores del comité. El concep-to básico es muy simple aunque de amplio alcance. MPEG-21 busca crear una estructura completa para la administración y uso de assets digitales incluyendo toda la infraestructura de soporte para las transacciones comerciales y administración de derechos que deben acompañar esta estructura. El enfoque es dirigido hacia “habilitar el uso transparente y creciente de los recursos multimedia por un rango amplio de redes y dispositivos”. El alcance del trabajo de MPEG-21 es indicado por los siete elementos estructurales definidos en el borrador del reporte técnico.

1. Se espera que la declaración del ítem digital “establezca una abstracción unifor-me y flexible y un esquema interoperable para definir los ítems digitales.” El es-quema debe ser abierto y extensible para cualquiera y todos los tipos de recur-sos de media y esquemas de descripción y deben soportar una estructura jerár-quica que sea fácil de consultar y navegar.

2. La representación del ítem digital de MPEG-21 es la tecnología que se usará para codificar el contenido y para proporcionar todos los mecanismos necesarios para sincronizar todos los elementos del contenido. Se espera que esta capa referencie al menos a MPEG-4.

3. La identificación y descripción del ítem digital proporcionará el marco de trabajo para la identificación y descripción de los ítems digitales (enlazando todos los elementos del contenido). Probablemente esto incluirá los esquemas de descrip-ción de MPEG-7, pero también debe incluir “[una] nueva generación de sistemas de identificación para soportar de forma efectiva, exacta y automatizada la admi-nistración de eventos y los reportes (transacciones de licencias, reglas de utiliza-ción, monitoreo y seguimiento, etc.).” Debe satisfacerá las necesidades de todas las clases de usuarios de MPEG-21.

La administración del contenido y el uso deben definir las interfases y protocolos para el almacenamiento, administración y descripción de los ítems digitales de MPEG-21. Se debe soportar el archivado y catalogado del contenido mientras se preserve el uso de los derechos y la capacidad de rastrear los cambios de los ítems y sus descripciones. Este elemento de MPEG-21 es posible que también respalde una forma de “comercialización” en la que los consumidores puedan intercambiar información personal para el acceso adecuado al contenido y la formalización de mecanismos para “canales personales” y construcciones similares. La administración de la propiedad intelectual y la protección es una componente esencial. Las controversias actuales que rodean a los archivos de audio en MP3 demuestran la necesidad de nuevos mecanismos de derechos de copia recono-cibles para el mundo digital. Se puede argüir que el contenido no tiene valor a menos que esté protegido. MPEG-21 se construirá sobre los trabajos actuales de MPEG-4 y MPEG-7, pero necesitará extensiones para acomodar nuevos tipos de ítems digitales y mecanismos de distribución. Las terminales y redes MPEG-21 direccionarán la distribución de ítems en un amplio rango de redes y la capacidad de entregar el contenido en un amplio rango de terminales. Conceptualmente una película debería ser distribuible con calidad completa de cine digital a un cine o con baja calidad a una red más lenta hasta un dispositivo de consumidor (a un precio diferente). En cualquier caso habrá algunas restricciones para el tipo y número de usos. El usuario no deberá darse cuenta de ninguno de los problemas y complejida-des asociadas con la entrega o reproducción del ítem. Finalmente existe la necesidad de un reporte de eventos para “normalizar la métrica e interfases para checar el desempeño de todos los eventos reporta-bles”. El ejemplo más obvio aquí es que si el sistema le permite al usuario tener acceso a un ítem protegido, ¡también se debe asegurar que se haga el pago apropiado!



Sección 5 –Streams elementales ► Figura 5-1 Un stream elemental es básicamente la salida en bruto del Encoder y no contiene nada más que lo necesario para que un Decoder haga la aproxi-mación a la imagen o audio originales. La sintaxis de la señal comprimida es definida en una forma rígida en MPEG de tal forma que los Decoders puedan garantizar que puedan trabajar con eso. El Decoder no es definido excepto en que debe producir de alguna forma la sintaxis adecuada. La ventaja de esta aproximación es que va de acuerdo con el mundo real en el que es más probable que haya muchos más Decoders que Encoders. Normalizando el Decoder se pueden hacer a bajo costo. En contraste, el Encoder puede ser más complejo y caro sin una gran penalización de costos pero con una calidad de imagen potencialmente mejor a medida que se incrementa la complejidad. Cuando el Encoder y el Decoder son diferen-tes en complejidad se dice que el sistema de codificación es asimétrico. La aproximación de MPEG también permite la posibilidad de que la calidad mejore a medida que los algoritmos de codificación se refinen al estar produciendo los streams de bits que pueden ser entendidos por los prime-ros Decoders. La aproximación también permite el uso de algoritmos de codificación de propietario que no necesitan llegar a ser de dominio público.

5.1 Sintaxis del stream elemental de Video La Figura 5-1 muestra la construcción del stream elemental de video. La unidad fundamental de información de la imagen es el bloque de DCT (Discrete Cosine Transform. Transformada discreta de coseno) que repre-senta un arreglo de píxeles de 8x8 que pueden ser Y, Cb o Cr. Los coefi-cientes de DC se envían primero y son representados con más exactitud que los otros coeficientes. Después se envían los coeficientes restantes y el código de final de bloque o EOB (End Of Block).

Los bloques son ensamblados en macrobloques que son las unidades fundamentales de una imagen y que pueden estar compensadas en movi-miento. Cada macrobloque tiene un vector de movimiento bidimensional en el encabezador. En las imágenes B-, los vectores pueden ser retrasados así como adelantados. La compensación de movimiento puede estar basa-da en campos o cuadros y esto se indica. La escala utilizada para la re-cuantización de movimientos también se indica. Usando los vectores, el Decoder obtiene información acerca de las imágenes anteriores y posterio-res para producir una imagen predicha. Los bloques son transformados en sentido inverso para producir una corrección de la imagen que se adiciona-rá a la imagen predicha para producir la salida decodificada. En la codifica-ción 4:2:0 cada macrobloque tendrá 4 bloques Y y dos bloques de diferen-cia de color. Para que sea posible identificar que bloque describe que componente los bloques se envían en un orden especificado. Los macrobloques son ensamblados en “slices” (“rebanadas”) que siempre deben representar bandas horizontales de imagen de izquierda a derecha. En MPEG, los “slices” pueden iniciar en cualquier punto y tener un tamaño arbitrario pero en ATSC deben iniciar en el extremo izquierdo de la imagen. Pueden existir muchos “slices” a todo lo ancho de la pantalla. El “slice” es la unidad fundamental de sincronización para la codificación de longitud variable y la diferencial. Los primeros vectores en un “slice” se envían en forma absoluta mientras que los vectores restantes se transmiten en forma diferencial. En las imágenes I-, los primeros coeficientes de DC en el “slice” se envían en forma absoluta y los coeficientes restantes en forma diferen-cial. En las imágenes diferenciales, no se espera correlación de esos coefi-cientes y esta técnica no es apropiada.



En el caso de un error de bit en el stream elemental, ya sea la deserializa-ción de los símbolos de longitud variable se romperá o los subsecuentes coeficientes diferencialmente codificados estarán incorrectos. La estructura del “slice” permite la recuperación proporcionando un punto de resincroni-zación en el stream de bits. Un número de “slices” son combinados para formar una imagen que esta en la parte activa de un campo o cuadro. El encabezador de la imagen define si la imagen fue codificada como I-, P- o B- e incluye una referencia temporal de tal forma que la imagen pueda ser presentada en el momento adecuado. En el caso de los “paneos” y “tilts”, los vectores en cada macro-bloque serán los mismos. Un vector global puede ser enviado para toda la imagen y los vectores individuales entonces se convertirán en diferencias de este valor global. Las imágenes se pueden combinar para producir un GOP que debe co-menzar (en orden de transmisión) con una imagen I-. El GOP es la unidad fundamental de codificación temporal. En la norma MPEG, el uso de un GOP es opcional pero es una necesidad práctica. Entre las imágenes I-, un número variable de imágenes P- y/o B- pueden ser colocadas como se describió en la sección 2. Un GOP puede ser abierto o cerrado. En un GOP cerrado, las últimas imágenes B- no requieren la imagen I- del siguiente GOP para decodificar y el stream de bits puede ser cortado al final del GOP. Si se usan los GOPs, muchos de ellos pueden ser combinados para produ-cir una secuencia de video. La secuencia comienza con un código de inicio de secuencia seguido por un encabezador de secuencia y termina con un código de fin de secuencia. Se pueden colocar encabezadores de secuen-cia adicionales en la secuencia. Esta aproximación permite que la decodifi-cación comience en cualquier parte de la secuencia como debe ocurrir con la reproducción de los discos de video digital y cassettes de cinta. El enca-bezador de secuencia especifica el tamaño vertical y horizontal de la ima-gen, la relación de aspecto, el formato de submuestreo de Croma, la rela-ción de imagen, el uso de exploración progresiva o entrelazada, el perfil, nivel y relación de bits y las matrices de cuantización utilizadas en las imágenes intra e intercodificadas. Sin los datos del encabezador de secuencia, un Decoder no puede enten-der el streams de bits y por tanto los encabezadores de secuencia se convierten en puntos de acceso en los que los Decoders pueden empezar la operación correcta. El espaciado de los puntos de entrada influye sobre el retraso para la decodificación correcta que pueda ocurrir cuando el espectador cambia de un canal de televisión al otro.

5.2 Streams elementales de audio Se pueden encajar varios tipos de audio en un múltiplex MPEG-2. Estos tipos incluyen el audio codificado de acuerdo con las capas de MPEG 1, 2, 3, o AC-3. El tipo de codificación de audio usado debe incluirse en un descriptor que un Decoder leerá con el fin de invocar el tipo apropiado de decodificación. El proceso de compresión de audio es muy diferente del proceso de video. No hay equivalente para los diferentes tipos de cuadro I-, P- y B- y los cuadros de audio contienen la misma cantidad de datos de audio. No hay equivalente de la codificación bidireccional y los cuadros de audio no son transmitidos de la secuencia. En el audio MPEG-2, el descriptor en el encabezador de la secuencia contiene la capa que se ha usado para comprimir el audio y el tipo de compresión usado (por ejemplo “joint stereo”), junto con la relación de muestreo original. La secuencia de audio es ensamblada a partir de un número de unidades de acceso o AU (Access Unit) que serán cuadros de audio codificados, Si se usa la codificación AC-3, como en ATSC, este uso será reflejado en el encabezador de secuencia. La unidad de acceso de audio (AU) es un cuadro de sincronía AC-3 como se describió en la Sección 3.7. El cuadro de sincronía AC-3 representa una extensión de tiempo equivalente a 1536 muestras de audio y será de 32 ms para el muestreo a 48-kHz y 48 ms para 32 kHz.



Sección 6 – Streams elementales paquetizados o PES (Packetized Elementary Streams) Para propósitos prácticos, los streams elementales continuos que transpor-tan audio o video de los compresores necesitan ser divididos en paquetes. Esos paquetes son identificados por encabezadores (headers) que contie-nen el estampado de tiempo para sincronización. Los paquetes PES se pueden usar para crear Streams de programa o Streams de transporte.

6.1 Paquetes PES En el PES, un stream elemental interminable es dividido en paquetes de un tamaño conveniente para la aplicación. Este tamaño debe ser de unos pocos cientos de kilobytes, aunque esto variará de acuerdo con la aplica-ción. Cada paquete es precedido por un encabezador de paquete de PES. La Figura 6-1 muestra el contenido de un encabezador. El paquete comienza con un prefijo de inicio de código de 24 bits y una ID de stream que identifi-ca el contenido del paquete como audio o video y otros más identifican el tipo de codificación de audio. Esos dos parámetros (prefijo de código de inicio e ID de stream) componen el código de inicio de paquete que identifi-ca el inicio de un paquete. Es importante no confundir el paquete en un PES con el paquete mucho menor usado en los streams de transporte que, desafortunadamente, comparten el mismo nombre. Debido a que MPEG solo define el stream de transporte, no el Encoder, un diseñador puede elegir construir un Multiplexor que convierta de streams elementales a streams de transporte en un solo paso. En este caso los paquetes PES podrían no existir nunca en una forma identificable sino que, en lugar de eso sean presentados lógicamente en el “payload” (carga útil) del stream de transporte.

6.2 Estampado de tiempo Después de la compresión, las imágenes se sacan de la secuencia debido a la codificación bidireccional. Estas requieren una cantidad variable de datos y están sujetas a retrasos variables debido a la multiplexión y trans-misión. Con el fin de mantener el audio y el video juntos, el estampado en tiempo se incorpora periódicamente en cada imagen, Un estampado de tiempo es un número de 33 bits que es una muestra de un contador controlado por un reloj de 90-kHz. Este reloj es obtenido divi-diendo el reloj del programa de 27-MHz entre 300. Ya que los tiempos de presentación están espaciados equitativamente, no es esencial incluir un estampado de tiempo por cada unidad de presentación, en lugar de eso, los estampados de tiempo pueden ser interpolados por el Decoder pero no pueden estar más separados que a 700 ms en los streams de programa o de transporte.

El estampado de tiempo indica a que punto particular en el tiempo pertene-ce un acceso particular. El Lip sync se obtiene incorporando estampados de tiempo en los encabezadores de los paquetes PES tanto de audio como de video. Cuando un Decoder recibe un paquete PES seleccionado, deco-difica cada unidad de acceso y lo envía a la RAM. Cuando el contador de tiempo-línea alcanza el valor del estampado de tiempo, la RAM es leída. Esta operación tiene dos resultados deseables. El primero es que se obtie-ne una corrección de base de tiempo efectiva en cada stream elemental. Segundo, los streams elementales de audio y video se pueden sincronizar juntos para hacer un programa.

6.3 PTS/DTS Cuando se usa la codificación bidireccional, se podría tener que decodificar una imagen en algún momento antes de que se presente para que pueda actuar como fuente de datos para una imagen B-, A pesar de eso, por ejemplo, las imágenes pueden ser presentadas en el orden IBBP, aunque se transmitirán en el orden IPBB. Consecuentemente existen dos tipos de estampado de tiempo. El estampado de tiempo de decodificación o DTS (Decode Time Stamp) indica el tiempo en el que una imagen se debe decodificar mientras que un estampado de tiempo de presentación o PTS (Presentation Time Stamp) indica cuando se debe presentar a la salida del Decoder. Las imágenes B- se decodifican y presentan simultáneamente de tal forma que solo contengan PTS. Cuando se recibe una secuencia IPBB las imáge-nes I- y P- deben ser decodificadas antes de la primera imagen B-. Un Decoder solo puede decodificar una imagen a la vez, por tanto, la imagen I- se decodifica y almacena primero. Mientras que se decodifica la imagen P-, la imagen I- decodificada es enviada a la salida para que pueda ser seguida por las imágenes B-. ►Figura 6-1



►Figura 6-2 La Figura 6-2 muestra que cuando una unidad de acceso que contiene una imagen I- es recibida tendrá tanto DTS como PTS en el encabezador y esos estampados de tiempo estarán separados por un periodo de imagen. Si se está usando la codificación bidireccional una imagen P- debe seguir y esta imagen también tiene estampados de tiempo DTS y PTS pero la separación entre los dos estampados de tiempo es de tres periodos de imagen para permitir la intermediación de las imágenes B-. Así, si se recibe una secuencia IPBB, la imagen I- estará retrasada por un periodo de ima-gen, P- tres periodos de imagen y B- dos que no estarán retrasadas en lo más mínimo y la secuencia de presentación se convertirá en IBBP.

Claramente, si la estructura del GOP es cambiada de tal forma que haya más imágenes B- entre I- y P-, la diferencia entre DTS y PTS en las imáge-nes P- será mayor. Las banderas de PTS/DTS en el encabezador de paquete se establece de tal forma que indiquen la presencia de solo el PTS o de ambos estampados de tiempo: PTS y DTS. Los paquetes de Audio pueden contener muchas unidades de acceso y el encabezador del paquete puede contener un PTS. Debido a que los paquetes de audio nunca se transmiten de la secuencia no hay DTS en un paquete de audio.



Sección 7 –Streams de Programa Los streams de programa son una forma de combinar varios streams de paquete PES y son muy ventajosos para aplicaciones de grabación como el DVD.

7.1 Grabación vs. Transmisión Para una calidad de imagen dada, la relación de datos del video comprimi-do variará con el contenido de la imagen. Un canal de relación de bits variable dará los mejores resultados. En la transmisión, la mayoría de canales prácticos son fijos y la relación de bits total se mantiene constante por medio del uso del “stuffing” (datos de relleno). En un DVD, el uso del stuffing es un desperdicio de la capacidad de alma-cenamiento; sin embargo, un medio de almacenamiento puede ser alentado o acelerado, ya sea físicamente o, en el caso de un controlador de disco, cambiando la relación de las requisiciones de transferencia de datos. Esta aproximación permite obtener un canal de relación variable sin penali-zación en la capacidad. Cando se reproduce un medio, la velocidad puede ser ajustada para mantener el Buffer de datos lleno a aproximadamente la mitad sin importar la relación de bits que puede cambiar dinámicamente. Si el Decoder lee el Buffer a una relación creciente tenderá a vaciarlo y el sistema de control simplemente incrementará la relación de acceso para restablecer el balance. Esta técnica solo funciona si el audio y el video fueron codificados con el mismo reloj; de otra forma, se esparcirán por toda la longitud de la grabación. Para satisfacer esos requerimientos conflictivos los streams de programa y transporte tienen que ser proyectados como alternativas. Un stream de programa funciona bien en un programa simple con relación de bits variable en un ambiente de grabación; un stream de transporte funcionará bien en programas múltiples en un ambiente de transmisión de relación de bits fija.

El problema del “genlocking” a la fuente no ocurre en un reproductor de DVD. El reproductor determina la base de tiempo del video con un genera-dor de pulsos de sincronía local (interno o externo) y obtiene simplemente los datos del disco con el fin de proporcionar imágenes con esa base de tiempo. En transmisión, el Decoder tiene que recrear la base de tiempo en el Encoder o se sufrirá de overflow o underflow. Así, un stream de transpor-te usará una referencia de reloj de programa o PCR (Program Clock Reference), mientras que un stream de programa no necesitará el reloj de programa.

7.2 Introducción a los streams de programa Un stream de programa es un múltiplex de paquete PES que transporta muchos streams elementales que fueron codificados usando el mismo reloj maestro o reloj de tiempo de sistema o STC (System Time Clock). Ese stream puede ser de video y sus streams de audio asociados o un programa multicanal de solo audio. El stream de video elemental es dividido en unidades de acceso o AUs, cada uno de los cuales contiene datos comprimidos que describen una imagen. Esas imágenes son identificadas como I-, P-, o B- y cada una lleva un número de AU que indica la secuencia de despliegue correcta. Una AU de video se convierte en un paquete de stream de programa. En video, esos paquetes varían en tamaño. Por ejemplo, un paquete de imagen I- será mucho más grande que un paquete de imagen B-. Las unidades de acceso de audio digital generalmente son del mismo tamaño y muchas de ellas son ensambladas en un paquete de stream de transporte, Esos paquetes no deben confundirse con los paquetes de stream de transporte que son más pequeños y de tamaño fijo. Las fronteras de las AUs de audio y video coinciden con el eje del tiempo pero esta falta de coincidencia no es un problema porque cada frontera tiene su propia estructura de estampado de tiempo.



Sección 8 – Streams de transporte Un stream de transporte es más que solo un múltiplex de muchos paquetes PES. En los streams de programa, los estampados de tiempo son suficien-tes para recrear el eje del tiempo porque el audio y el video están “amarra-dos” a un reloj común. Para transmisión, con una red de datos a distancia hay un requerimiento adicional para recrear el reloj para cada programa en el Decoder. Esto requiere una capa adicional de sintaxis para proporcionar señales PCR.

8.1 La función del Stream de transporte El stream de transporte transporta muchos programas diferentes y cada uno puede usar un factor de compresión diferente y una relación de bits que puede cambiar dinámicamente aún cuando la relación de bits en gene-ral permanezca constante. Este comportamiento es llamado multiplexión estadística y le permite a un programa que está manejando material difícil “robarse” ancho de banda de un programa que este manejando material sencillo. Cada PES de video puede tener asociado un número diferente de PES de audio y datos. A pesar de esa flexibilidad un Decoder debe ser capaz de cambiar de un programa al siguiente y seleccionar correctamente los canales de audio y datos. Algunos de los programas pueden estar protegidos por lo que solo podrían ser vistos por aquellos que paguen una suscripción o cuota. El stream de transporte debe contener información de CA para administrar esa protección. El stream de transporte contiene un PSI para manejar esas tareas. La capa de transporte convierte los datos del PES en pequeños paquetes de tamaño constante (adicionando bits de relleno si fuera necesario) que

están auto contenidos. Cuando esos paquetes arriban al Decoder, puede haber jitter en la temporalización. El uso de la multiplexión por división de tiempo también causa retraso pero este factor no es fijo debido a que la proporción del stream de bits asignado a cada programa necesita que no sea fijo. El estampado de tiempo es parte de la solución pero solo funciona si se dispone de un reloj estable. El stream de transporte debe contener más datos pertenecientes a la recreación del reloj estable. La operación del equipo de producción de video digital depende fuertemente de la distribu-ción de un reloj de sistema estable para la sincronización. Para la producción de video se usa el “genlock” pero, a grandes distancias, la distribución de un reloj separado no es práctica. En un stream de trans-porte, los diferentes programas se pueden haber originado en diferentes lugares que no estén necesariamente sincronizados. Como resultado, el stream de transporte tiene que proporcionar un medio separado de sincronización para cada programa. Este método adicional de sincronización se llama PCR y recrea un reloj de referencia estable que puede ser dividido para crear una línea de tiempo en el Decoder de tal forma que el estampado de tiempo para los streams elementales en cada programa se vuelva útil. Consecuentemente, una definición de un programa es un juego de streams elementales que com-parten la misma referencia de tiempo. En un stream de transporte de programa simple o SPTS (Single Program Transport Stream), habrá un canal de PCR que recree un reloj de programa para audio y video. El SPTS frecuentemente es usado como comunicación entre un Coder de audio/video y un Multiplexor.



►Figura 8-1 8.2 Paquetes La Figura 8-1 muestra la estructura de un paquete de stream de transporte. El tamaño es constante, 188 bytes y siempre está dividido en un encabeza-dor o “header” y una carga útil o “payload”. La Figura 8-1 muestra el enca-bezador mínimo de 4 bytes. En este encabezador, la información más importante es:

► El sync byte. Este byte es reconocido por el Decoder para que el encabeza-

dor y el payload (carga útil) puedan ser deserializados.

► El indicador de error de transporte. Este indicador es establecido si la capa

de corrección de error que está por encima de la capa de transporte está ex-

perimentando una relación de error de bit o BER bruta (Bit Error Rate) que

sea demasiado alta para ser corregible. Indica que el paquete puede conte-

ner errores, vea la Sección 10 - Introducción a DVB y ATSC para los detalles

acerca de la capa de corrección de errores.

► La identificación de paquetes o PID (Packet IDentification). Este código de

13 bits se usa para distinguir entre los diferentes tipos de paquetes. Más

adelante se dirá más acerca del PID.

► El contador de continuidad. Este valor de cuatro bits se incrementado por el

Multiplexor a medida que cada nuevo paquete que tenga el mismo PID se

envíe. Se usa para determinar si cualquiera de los paquetes se pierde, repite

o está fuera de la secuencia.

En algunos casos se necesita más información de encabezador y si ese es el caso, los bits de control del campo de adaptación se ajustan para indicar

que el encabezador es más grande que el normal. La Figura 8-1b muestra que cuando esto sucede la longitud extra del encabezador se describe con el código de longitud de campo de adaptación. Donde se extienda el enca-bezador, la carga útil se hará más pequeña para mantener una longitud de paquete constante.

8.3 Referencia del reloj de programa o PCR (Program Clock Reference) El Encoder usado para un programa particular tendrá un reloj de programa de 27-MHz. En el caso de una entrada SDI (Serial Digital Interface) el reloj de bits puede dividirse entre 10 para producir el reloj de programa de Enco-der. Donde muchos programas se originen en la misma casa de producción es posible que todos ellos tengan el mismo reloj. En el caso de una entrada de video analógico, el periodo de sincronía horizontal necesitará ser multi-plicado por una constante en un PLL (Phase-Locked Loop o lazo de fase amarrada) para producir 27 MHz.



►Figura 8-2 El campo de adaptación en el encabezador de paquete se usa periódica-mente para incluir el código PCR que permita la generación de un reloj amarrado al Decoder. Si el Encoder o un Remultiplexor tienen que conmu-tar fuentes, el PCR puede tener una discontinuidad; el contador de conti-nuidad también puede ser perturbado. Ese evento es manejado por el indicador de discontinuidad que le dice al Decoder que debe esperar una perturbación, de otra forma una discontinuidad será una condición de error. La Figura 8-2 muestra como el Decoder usa el PCR para recrear una versión remota del reloj de 27-MHz para cada programa. El reloj del Enco-der controla un contador binario que está corriendo constantemente y el valor de esos contadores se muestrea periódicamente y se coloca en los campos de adaptación del encabezador como PCR. El PCR es un número de 42 bits que es representado por una base PCR de 33 bits más una extensión PCR de 9 bits para proporcionar una resolución más alta (El PCR base, como el PTS, es un número de 33 bits que es una muestra de un contador controlado por un reloj de 90 kHz). A los paquetes generados por cada encoder se les dan un PID diferente. El Decoder reconoce los paque-tes con el PID correcto para el programa seleccionado e ignora los otros. En el Decoder, un oscilador controlado por voltaje o VCO (Voltage Con-trolled Oscillator) genera un reloj nominal de 27 MHz y esto controlará un contador de PCR local. El PCR local se compara con el PCR del encabe-zador del paquete y la diferencia es el error de fase de PCR. Este error es filtrado para controlar el VCO que eventualmente igualará el conteo del PCR local al del encabezador del PCR. Un filtraje pesado del VCO asegura que el jitter de transmisión del PCR no modula el reloj. El indicador de

discontinuidad aplicará un reset al conteo del PCR local y, opcionalmente, puede usarse para reducir el filtraje para ayudar al sistema a amarrarse rápidamente a la nueva temporalización. MPEG requiere que los PCR se envíen a una relación de cuando menos 10 PCRs por segundo, mientras que la DVB especifica un mínimo de 25 PCRs por segundo.

8.4 Identificación de paquete o PID (Packet IDentification) Un campo de 13 bits en el encabezador del paquete de transporte contiene el código de identificación de paquete o PID (Packet IDentification Code). El PID es usado por el Demultiplexor para distinguir entre los paquetes que contienen diferentes tipos de información. La relación de bits del stream de transporte debe ser constante aún cuando la suma de las relaciones de todos los diferentes Streams que contenga pueda variar. Este requerimien-to es manejado por el uso de paquetes nulos. Si la relación real del payload cae se insertan más paquetes nulos. Los paquetes nulos siempre tienen la misma PID que es de 8191 (trece unos en la representación binaria).



►Figura 8-3 En un stream de transporte dado, todos los paquetes que pertenecen a un stream elemental dado tendrán el mismo PID. El demultiplexor puede seleccionar fácilmente todos los datos para un stream elemental dado simplemente aceptando solo los paquetes con el PID adecuado. Los datos para un programa completo pueden ser seleccionados usando las PIDs para streams de video, audio y datos como subtítulos o teletexto. El Demul-tiplexor puede seleccionar correctamente los paquetes si puede asociarlos correctamente con el stream elemental al cual pertenece. El Demultiplexor puede hacer esta tarea solo si conoce lo que son las PIDs adecuadas. Esta es la función del PSI.

8.5 Información específica del programa (Program Specific Informa-tion) El PSI es transportado por paquetes que tienen PIDs únicas, algunos de los cuales están normalizados y otros son especificados por la Tabla de aso-ciación de programa o PAT (Program Association Table), la Tabla de acce-so condicional o CAT (Conditional Access Table) y la Tabla de descripción del stream de transporte o TSDT (Transport Stream Description Table). Esos paquetes deben ser incluidos periódicamente en cada stream de transporte. La PAT siempre tiene un PID de 0, el CAT siempre tiene un PID de 1 y el TSDT siempre tiene un PID de 2. Esos valores y la PID de paque-te nulo de 8191 son las únicas PIDs fijadas por la norma MPEG. El Demul-tiplexor debe determinar todas las PIDs restantes accesando las tablas apropiadas; sin embargo, hay algunas restricciones en el uso de las PIDs en ATSC y DVB. En esto (y otras cosas), MPEG y DVB/ATSC no son

completamente intercambiables, Todos los streams de transporte de DVB y ATSC deben cumplir con la norma MPEG-2 (ISO/IEC 13818-1), pero no todos los streams de transporte MPEG-2 cumplirán con las normas de ATSC (A/65A) o DVB (EN 300 468). Los programas que existan en el stream de transporte están enlistados en los paquetes (PID = 0) de la Tabla de asociación de programa o PAT (Pro-gram Association Table) que transporta el PID de cada paquete de PMT, La primera entrada en la PAT, program 0, está reservado para datos de red y contiene la PID de los paquetes de la Tabla de información de la red o NIT (Network Information Table). El uso de la NIT es opcional en MPEG-2 pero obligatoria en DVB. Las PIDs para los Mensajes de control de derechos o ECM (Entitlement Control Messages) y de los Mensajes de administración de derechos o EMM (Entitlement Management Messages) están enlistadas en los paque-tes de la Tabla de acceso condicional o CAT (Conditional Access Table) (PID = 1). Como se muestra en la Figura 8-3, las PIDs de los streams elementales de video, audio, y datos que pertenezcan al mismo programa se enlistan en los paquetes de la Tabla de mapa de programa o PMT (Program Map Table). Cada paquete de PMT normalmente tiene su propia PID, pero MPEG-2 no hace que esto sea obligatorio. El número de programa dentro de cada PMT únicamente definirá cada PMT.



Una Tabla de información de red o NIT (Network Information Table) dada contiene más detalles que solo los del stream de transporte que lo lleva; también se incluyen los detalles de otros streams de transporte que puedan estar disponibles en el mismo Decoder, por ejemplo, sintonizando un dife-rente canal de RF o apuntando el plato a un satélite diferente. La NIT puede enlistar un número de otros streams de transporte y cada uno debe tener un descriptor que especifique la frecuencia de radio, posición orbital y así sucesivamente. En DVB, la metadata adicional, conocida como DVB-SI, se incluye y la NIT es considerada como parte de la DVB-SI. Esta operación es discutida en la Sección 10 – Introducción a DVB y ATSC. Cuando se discute la materia en general, se usa el término PSI/SI. Hasta recibir el primer stream de transporte el demultiplexor debe buscar las PIDs 0 y 1 en los encabezadores del paquete, Todos los paquetes con PID 0 contienen la PAT. Todos los paquetes con PID 1 contienen datos de CAT.

Leyendo la PAT, el Demultiplexor puede encontrar las PIDs de la NIT y de cada Tabla de mapeo de programa o PMT (Program Map Table). Encon-trando las PMTs, el Demultiplexor podrá encontrar las PIDs de cada stream elemental. Consecuentemente, si la decodificación de un programa particular se requiere, las referencias a la PAT y luego a la PMT será todo lo que se necesita para encontrar las PIDs de todos los streams elementales en el programa. Si el programa está encriptado, el acceso al CAT también será necesario. Ya que la demultiplexión es imposible sin el PAT, la velocidad de cerrado es una función de que tan frecuentemente los paquetes de PAT son enviados. MPEG especifica un intervalo máximo de 0.5 segundos para los paquetes de PAT y los paquetes de PMT que estén referidos a ellos en los paquetes de PAT. En DVB y ATSC, el NIT puede residir en paquetes que tienen un PID específico.



Sección 9 –Modulación digital ►Figura 9-1

Los sistemas MPEG codifican y empacan video, audio y otros datos. Para el almacenamiento, el stream de datos resultante puede ser grabado en un disco duro o quizá en DVD. Para otras aplicaciones, los datos MPEG, usualmente en la forma de un stream de transporte, tienen que ser envia-dos de un lugar a otro o a muchos lugares. Los sistemas de televisión usan cable, satélite y transmisión terrestre en varias formas para la contribución, distribución y broadcast. Todos esos mecanismos de transporte requieren que los datos sean modulados en alguna portadora. Esta sección propor-ciona una breve introducción a los esquemas de modulación digital que se usan para lograr esto. Esta Sección discute solo las técnicas de modulación, Otros procesos son necesarios para hacer que el stream de datos sea adecuado para la trans-misión y dependerán tanto de la modulación elegida como de las caracte-rísticas del canal. Esas técnicas se discutirán en la Sección 10.

9.1 Principios de modulación Una portadora continua no transporta ninguna información a menos que sea modificada en alguna forma por la información a transmitir. Una porta-dora puede ser modificada en tres formas, cambiando su amplitud, frecuen-cia o fase. La frecuencia y la fase, por supuesto, están íntimamente relacio-nadas. Aunque generalmente son tratadas como tipos de modulación separadas, la distinción se puede volver muy borrosa; algunos sistemas de “modulación en frecuencia” son implementados por “moduladores de fase”.

►Figura 9-2

9.2 Modulación Analógica

En el mundo analógico, la amplitud o la frecuencia de una portadora es cambiada (modulada), de acuerdo a la amplitud de una señal de audio o video, usualmente de acuerdo con una ley lineal. La modulación de fase también se usa en los sistemas analógicos, el ejemplo más obvio es la modulación de las señales de diferencia de color en una subportadora de color en los sistemas de televisión NTSC y PAL. Esta operación familiar proporciona un ejemplo útil. Podemos pensar en la información de color en dos formas. Puede ser expresada como la fase de un ángulo (relacionado con el tinte o “hue”) más una amplitud (relacionada con la saturación) o como los valores de dos señales de diferencia de color, B-Y y R-Y. Si las componentes de diferencia de color son tratadas como valores de “x” y “y” en una gráfica, las dos representaciones son vistas como íntimamente relacionadas como se ilustra en la Figura 9.1. Esta figura es similar al bien conocido despliegue de un vectorscopio.

9.3 Modulación de cuadratura La Figura 9.2 muestra como podemos modular una portadora con dos señales diferentes usando la técnica conocida como “modulación de cua-dratura”. Una portadora simple es dividida en dos partes y una de ellas es retrasada por un tiempo equivalente a un cuarto del tiempo de ciclo de la portadora. Esto genera una portadora de la misma frecuencia pero con la fase corrida 90º de la original. Las dos portadoras son moduladas en ampli-tud con una señal apropiada y las dos portadoras moduladas son adiciona-das juntas. Esto genera una señal simple con una amplitud y fase determi-nadas por las amplitudes de las dos señales moduladoras.



►Figura 9-3 La demodulación se logra con un proceso casi idéntico; la señal recibida se envía a los dos Demoduladores. En cada Demodulador la señal es multipli-cada por una señal del oscilador local, sincronizada a la señal recibida. Las señales de los dos osciladores locales están a 90º y cada demodulador recobra un eje de la modulación de cuadratura.

9.4 Sistemas de Modulación Digital Simple La mayoría de Sistemas de modulación digital simple usan alguna forma de modulación de cuadratura; los dos ejes usualmente son designados I y Q. Algunas veces solo un eje de modulación se usa. Todos los esquemas de modulación digital representan un compromiso de eficiencia del ancho de banda, robustez y complejidad. La relación de símbolos es el factor principal para determinar el ancho de banda de la señal transmitida. La relación de símbolos es la relación a la cual la modu-lación se cambia por lo que es la misma que el ancho de banda de las señales moduladoras Algunos sistemas de modulación digital simples solo llevan un bit de infor-mación por símbolo. En otras palabras, cada símbolo puede representar uno de dos posibles estados que representan un cero o uno binario. En ese caso, la relación de bits del sistema es el mismo que la relación de símbolo; sin embargo, otros sistemas tienen muchos estados posibles por cada símbolo por lo que pueden transportar más de 1 bit de información por símbolo. Generalmente el número de estados está en potencias de dos por lo que la relación de bits del sistema es algún entero múltiplo de la relación de símbolo. Los sistemas de modulación digital frecuentemente son etiquetados de acuerdo con el tipo de modulación precedidos por un número que represen-ta el número de estados por cada símbolo. Por ejemplo, 4QAM describe modulación de amplitud en cuadratura con cuatro estados posibles por cada símbolo. Cuatro estados que pueden transportar dos bits de informa-ción (00, 01, 10, 11), por lo que la relación de bits de un sistema 4QAM es del doble de la relación de símbolo.

►Figura 9-4 Los sistemas de modulación digital más simples transportan un bit de información por símbolo. Cada símbolo tiene dos estados posibles que representan el cero y el uno binarios, Los estados pueden ser creados por modulación de amplitud, frecuencia o fase, pero la modulación de fase y frecuencia son las más comunes. El “llaveo” (keying) de corrimiento de frecuencia binaria (BFSK o 2FSK) usa una frecuencia de portadora para representar un cero binario y una frecuencia diferente para representar un uno binario, Algunas veces la diferencia de frecuencia es muy pequeña y es lograda por un modulador de fase. El “llaveo” (keying) de corrimiento de fase binaria (BPSK o 2PSK) usa una fase de la portadora (amplitud constante) para representar el cero binario y la fase inversa (180º de corrimiento de fase) para representar un 1 binario. Los posibles estados diferentes de un símbolo usualmente son mostrados en un diagrama de constelación que muestra las varias combinaciones resultantes de los valores permitidos de las señales moduladoras de I y Q. El diagrama de constelación para BPSK, mostrado en la Figura 9.3, es muy simple; solo uno de los ejes se usa y solo hay dos valores permitidos. Esos sistemas pueden ser muy robustos; el receptor necesita solo la sufi-ciente señal (o relación señal a ruido) para determinar cual de los dos posibles estados ha sido transmitido para cada símbolo; sin embargo, no usan el espectro eficientemente; el ancho de banda nominalmente es el mismo que la relación de bits. Esos sistemas se usan en trayectorias de transmisión muy dificultosas como es la telemetría en el espacio profundo.

9.5 “Llaveo” (Keying) de corrimiento de fase El BPSK o 2PSK se describió en la Sección previa. Otras formas de modu-lación PSK usa ambos ejes, I y Q. El “Llaveo” de corrimiento de fase cua-ternario (QPSK, también conocido como Llaveo de corrimiento de fase en cuadratura) es la más común, y usa dos valores en cada eje. El diagrama de constelación es mostrado en la Figura 9.4. El QPSK tiene cuatro estados posibles por símbolo, por lo que cada uno de ellos transporta dos bits de información; un posible mapeo de estados a valores binarios se muestra en la Figura. El QPSK se usa extensamente en comunicaciones por satélite.



►Figura 9-5 El 8PSK es menos común, pero también se usa en sistemas de satélite, particularmente en Japón. El diagrama de constelación se muestra en la Figura 9-5. El 8PSK transporta tres bits de información en cada símbolo por lo que la relación de bits es de tres veces la relación de símbolos

9.6 Modulación de amplitud de cuadratura o QAM (Quadrature Ampli-tude Modulation) La modulación de amplitud de cuadratura o QAM (Quadrature Amplitude modulation) es la base de muchos sistemas de transmisión. Se usan los dos ejes I y Q para la modulación y dependiendo de la variante particular se permiten dos o más niveles de amplitud para cada eje. La variante más simple es 4QAM en la que solo se usan dos valores para cada eje, proporcionando 4 estados posibles para cada símbolo. El diagra-ma de constelación se muestra en la Figura 9-6, en la que se verá que el 4QAM es idéntico al QPSK y transporta dos bits por símbolo. ►Figura 9-7

►Figura 9-6 El 16QAM usa 4 valores en cada eje proporcionando 16 estados posibles. El sistema 16QAM transporta 4 bits por símbolo. Si 6 valores se permiten para cada eje de modulación hay un total de 36 estados posibles. Cinco bits pueden ser transportados usando solo 32 estados por lo que 4 de las posibles combinaciones no se usan en 32QAM. El diagrama de constela-ción para 16QAM es mostrado en la Figura 9-7 y para 32QAM se muestra en la Figura 9-8. En 32QAM los cuatro estados de “esquina” no se usan; esos son los estados que representarían la amplitud más grande y por tanto, la potencia más alta del transmisor. Las Figuras 9-7 y 9-8 también ayudan a mostrar el compromiso entre la relación de bits y la robustez. En la presencia de ruido o jitter, el espacia-miento más pequeño de los estados en el 32QAM (a la misma potencia transmitida) hará más probables los errores de decodificación. Puesto en otra forma, entre más estados posibles por símbolo haya, mejor será la relación señal a ruido requerida para una relación de error dada. ►Figura 9-8



►Figura 9-9 Cuando se puede garantizar una buena relación señal a ruido, se pueden usar aún mayores densidades de constelación. 64QAM usa 8 valores en cada eje y transporta 6 bits por símbolo. 64 QAM es el esquema de modu-lación para cable que más se usa a nivel mundial ya que proporciona un buen compromiso entre robustez y compatibilidad con infraestructuras de cable heredadas. 256QAM se usa en algunos de los sistemas de televisión por cable más actuales, tiene 16 valores permitidos por cada eje de modu-lación y transporta 8 bits por símbolo.

9.7 Modulación de banda lateral vestigial o VSB (Vestigial Sideband Modulation) Cuando se modula una portadora se generan bandas laterales por arriba y por abajo de la frecuencia de la portadora. Por ejemplo, un sistema QAM con una relación de símbolos de 3 mega símbolos por segundo tendrá bandas laterales inferior y superior de unos 3 MHz de ancho, requiriendo un ancho de banda de canal nominal de 6 MHz. ►Figura 9-11

►Figura 9-10 Para recuperar la información tanto de amplitud como de fase (o ambos ejes de la modulación en cuadratura), ambas bandas laterales se deben recuperar en el receptor. Los sistemas de banda lateral vestigial eliminan la mayor parte de la banda lateral antes de la transmisión por lo que solo un eje de modulación podrá recuperarse (una interpretación alternativa es decir que el otro eje de modulación se usa para suprimir la banda lateral no deseada); 2VSB tiene la misma constelación que BPSK. La Figura 9-9 muestra los diagramas de constelación para 4VSB y la Figura 9-10 muestra 8VSB, transportando respectivamente dos y tres bits por símbolo. La modulación 8VSB la usa en Estados Unidos la norma de televisión digital ATSC. 4VSB fue propuesta originalmente, proporciona 2 bits por símbolo; sin embargo, se encontró que 8VSB, junto con la codificación Trellis (vea la Sección 10.6) y la corrección de errores interna convolucional proporciona la misma relación de datos con un desempeño mejorado de relación señal a ruido.

9.8 División Multiplexada de frecuencias ortogonalmente codificadas o COFDM (Coded Orthogonal Frequency Division Multiplex) En los sistemas anteriores, una señal de banda base es proporcionada a los moduladores que operan sobre una portadora simple para producir la banda(s) transmitida(s). Una alternativa a un sistema de banda ancha es una que produzca muchas portadoras de banda estrecha con un espaciado cuidadosamente regulado. La Figura 9-11A muestra que una portadora modulada digitalmente tiene un espectro nulo de cada lado. Otra portadora idéntica puede ser colocada aquí sin interferencias porque ambas son mutuamente ortogonales como se muestra en la Figura 9-11b. Este es el principio del OFDM (Orthogonal Frequency Division Multiplexing. Multi-plexión de división de frecuencia ortogonal). En la práctica, una variante conocida como Multiplexión de división de frecuencia ortogonal codificada o COFDM mejora el desempeño dramáticamente en condiciones de canal



que no son las ideales con el uso de la codificación convolucional Viterbi descrita en la siguiente sección. La COFDM se usa en el sistema de trans-misión digital de televisión terrestre DVB-T. Cada portadora en un sistema OFDM puede ser modulado con cualquiera de las técnicas descritas en esta sección. En la práctica la que generalmen-te se usa es la QAM; 16QAM y 64QAM son las más comunes. No es nece-sario usar todas las portadoras. Por ejemplo, si se sabe que una parte del canal está sujeto a un alto grado de interferencia, las portadoras afectadas se pueden omitir. El número de portadoras en un sistema OFDM puede ser muy grande. DVB-T tiene opciones para 1705 o 6817 portadoras (conocidos como sistemas 2k y 8k). Debido a que el ancho de banda asignado a cada porta-dora es pequeño, la relación de símbolos es por consiguiente pequeña y la longitud de tiempo para transmitir cada símbolo se incrementa. Esta es la clave de la tolerancia del OFDM a la interferencia de trayectorias múltiples. En un sistema de portadora simple, como 8VSB, una relación de datos alta implica que el tiempo del símbolo sea muy corto. En el caso del sistema de televisión digital ATSC, algunos de los 11 millones de símbolos se transmi-ten cada segundo dándonos una duración de símbolo de menos de 100 ns. Esto implica que aún un retraso muy corto de trayectorias múltiples creará una interferencia intersímbolo ya que la señal retrasada que representa un símbolo llegará durante la recepción del símbolo subsiguiente. En contraste, un sistema OFDM con cientos de portadoras tendrá un tiem-po de símbolo en el orden de cientos de micro segundos (dependiendo de la relación de datos y la modulación utilizada). La interferencia Intersímbolo puede ser virtualmente eliminada adicionando deliberadamente una “banda de guarda” a cada símbolo haciendo que este sea más largo que lo necesa-rio. Esto reduce la relación de símbolos pero solo a un grado relativamente pequeño. Por ejemplo, si la duración nominal del símbolo es de 200 µs, una

banda de guarda de 50 µs reducirá la relación del símbolo en solo 20% y la eliminación de la interferencia intersímbolo puede permitir que se use una constelación de orden más alto, quizá más que para compensar esa pérdi-da. Esta técnica no es práctica para un sistema de portadora simple de banda ancha. Como ejemplo, la misma banda de guarda de 50 µs con un tiempo de símbolo de 100 ns ¡Reducirá la relación de datos a una fracción de 1%! Esta tolerancia a la interferencia de trayectoria múltiple también hace que los sistemas COFDM sean adecuados para redes de frecuencia única en la que dos o más transmisores sincronizados emiten la misma señal. Un receptor puede, dependiendo de su localización y sistema de antena, recibir señales de más de un transmisor en diferentes momentos. Si las longitudes de las trayectorias son radicalmente diferentes, la señal principal probable-mente será mucho mas intensa que la señal secundaria y la interferencia será mínima. Si las longitudes de las trayectorias y la intensidad de la señal son similares, la banda de guarda evitará la interferencia intersímbolo. Los sistemas COFDM son muy flexibles y pueden ser “entonados” para llenar una amplia variedad de requerimientos de transmisión pero, como siempre, la incrementada robustez es a costo de la relación de datos. Hay muchos argumentos acerca de los méritos relativos de los sistemas de portadora simple y de portadoras múltiples pero generalmente se cree que bajo condiciones de canal simple, el COFDM requiere de alguna forma más potencia que VSB para la misma cobertura a la misma relación de datos. El COFDM también tiene una mayor relación pico a promedio en el transmisor que puede provocar más interferencias a otros servicios; sin embargo, muchos creen que en situaciones complejas de trayectorias múltiples como los “cañones urbanos” de la ciudad, el COFDM puede proporcionar una recepción más confiable.



9.9 Servicios integrados de transmisión de datos o ISDB (Integrated Services Data Broadcasting) Los Servicios integrados de transmisión de datos o ISDB (Integrated ser-vices data broadcasting) son un desarrollo que usa muchos esquemas de modulación y han sido desarrollados para los servicios de televisión digital en Japón. Está diseñado para respaldar sistemas jerárquicos de muchos niveles. Se puede usar, por ejemplo, para proporcionar simultáneamente una recepción de relación de datos a móviles bajo condiciones excepcio-nalmente dificultosas, relaciones de datos intermedias (definición estándar) para la recepción estática en la periferia y altas relaciones de datos (quizá para HDTV) para buenas condiciones de recepción. Hay tres sistemas de modulación ISDB actualmente en uso en Japón:

9.9.1 Sistema de satélite ISDB-S Lanzado en Diciembre de 2000, ISDB-S le permitió a los “broadcasters” compartir un “transponder” de satélite, También es referido como BS-digital o CS-digital cuando el segmento de espacio es un satélite de transmisión o uno de comunicaciones respectivamente. Se pueden usar hasta 8 streams de transporte en una forma que deben acordar quienes comparten el transponder. La relación de bits agregada dependerá del ancho de banda del transponder y el modo de modulación utilizada. Por ejemplo, para un transponder de 34.5 MHz, la relación máxi-ma incluyendo la corrección de errores adelantada es de 56.610 Mbits/s. La modulación jerárquica permite variar el modo de modulación en base a paquete a paquete dentro de un marco de 48 paquetes. Cada paquete es asignado a un “spot” de modulación. Se soportan 4 modos de modulación BSPK (1/2), QPSK (a 7/8) y TC8PSK. El número de “slots” varía de acuerdo al modo utilizado.

9.9.2 Sistema de cable ISDB-C La característica principal del sistema es que transmite streams de trans-porte múltiples en una portadora 64 QAM simple. El sistema fue desarrolla-do para ser capaz de retransmitir eficientemente la información transporta-da en señales ISDB-S. Típicamente se transmite un máximo de 52.17 Mbits/s de información en una portadora BS-digital. La relación de informa-ción de una señal 64 QAM/6 MHz es de 29.162 Mbits/s. De aquí que cuan-do menos se deben usar dos canales de televisión por cable para retrans-mitir la información de una portadora BS simple. El servicio digital BS completo consiste de 4 empresas de broadcast y ocupa aproximadamente 174 MHz incluyendo las bandas de guarda. Usando canales de cable ISDB-C se necesitarían 8 canales de cable para transportar esta información mientras que se requerirían 29 canales usando la transmisión convencional por cable de un stream de transporte por portadora. Hay 52 “slots” de modulación más 1 “slot” más para el encabezador de sincronización TSMF (Transport Stream Multiplexing Frame. Marco de multiplexión del stream de transporte).

9.9.3 Modulación terrestre ISDB-T El canal ISDB-T está dividido en 13 segmentos (típicamente 400-500 kHz de ancho), y se usa una transmisión COFDM separada para cada segmen-to. Todos los parámetros que afectan la robustez (número de portadoras, longitud de la banda de guarda, tipo de modulación, codificación de convo-lución) pueden elegirse por separado para cada capa de la jerarquía. Por ejemplo, el segmento más robusto puede usar una banda de guarda ancha, modulación QPSK y 1/2 codificación de convolución. El nivel más alto podría usar una banda de guarda más corta, 64QAM y 7/8 de codificación de convolución – proporcionando muchas veces la relación de datos del segmento robusto. El segmento central puede ser usado para la recepción parcial diseñada para permitir que un receptor de banda estrecha reciba solo ese segmento. En OFDM normal, el ancho de banda del canal completo representa una capa simple. Las portadoras usadas se espacian por todo el ancho de banda como juegos múltiples de cierta frecuencia. En ISDB-T el ancho de banda del canal de 5.6 MHz se divide en 13 segmentos y cada uno de ellos tiene un ancho de banda de 429 kHz. La transmisión jerárquica de ISDB-T se logra transmitiendo grupos de segmentos OFDM que tienen diferentes parámetros de transmisión. Esos grupos de capas constituyen las capas. En la modulación no jerárquica se usa el mismo esquema de modulación para todos los 13 segmentos.

9.9.4 El ISDB en resumen ISDB-S proporciona un medio de aplicar diferentes modos de modulación a múltiples streams de transporte y transmitirlos en un canal de 34.5 MHz en una sola portadora. ISDB-C proporciona un medio de transmitir múltiples streams de transporte en un canal simple de 6 MHz con una portadora simple pero con un modo de modulación común. ISDB-T tiene que ver con hasta las tres tipos de transmisiones del mismo stream de transporte en un simple canal de 6 MHz.



Sección 10 – Introducción a DVB y ATSC ►Figura 10-1 Ya se está usando la compresión MPEG para broadcast y se hará más importante a futuro. Esta sección discute los requerimientos adicionales para la transmisión digital de televisión de acuerdo a como es implementa-da por las dos normas principales de DTV.

10.1 Una vista general ATSC (Advanced Television Systems Committee. Comité de sistemas de Televisión avanzada) es una organización Norteamericana que define las normas para la transmisión digital terrestre. DVB se refiere al Proyecto de Broadcast de video digital y a las normas y prácticas establecidas para el proyecto DVB. Este proyecto originalmente fue Europeo pero produce normas y guías aceptadas en muchas áreas del mundo. Esas normas y guías comprenden todos los medios de transmisión incluyendo satélite, cable y terrestre. El broadcast digital tiene diferentes requerimientos de distribución y trans-misión como se muestra en la Figura 10.1. Las compañías de broadcast producirán streams de transporte que contengan muchos programas de televisión. Los streams de transporte no tienen ninguna protección contra errores y para datos comprimidos, el efecto de los errores es muy serio. Los streams de transporte necesitan ser entregados libres de errores a los transmisores, “subidas” de satélite y cabeceras de cable. En ese contexto, “libre de errores” implica una relación de errores de bit o BER (Bit Error

Rate) de 1 en 10-11 o mejor. Esta tarea normalmente es confiada a los operadores de redes de telecomunicaciones quienes usan una capa adicio-nal de corrección de errores como sea necesario (las estrategias de correc-ción de errores se seleccionan en el canal de transmisión). Esta capa debe ser transparente para el lugar de destino. Una compañía de broadcast particular u operador de cable podría no querer todos los programas de un stream de transporte. Muchos stream de transporte pueden ser recibidos y se puede hacer una selección de canales para luego codificarlos en un stream de transporte de salida simple usando un remultiplexor. La configuración puede cambiar dinámicamente. El broadcast en el dominio digital consiste en llevar todo el stream de transporte al espectador. Sin importar si el canal es cable, satélite o terres-tre, el problema es más o menos el mismo. La metadata que describe la transmisión debe ser codificada en el stream de transporte en una forma normalizada. En DVB, esta metadata es llamada “servicio de información” (DVB-SI) e incluye servicios como teletexto así como los detalles acerca de los programas transmitidos tanto dentro de sí mismo como de otras múlti-plex. En broadcast hay mucho menos control sobre la calidad de la señal y el ruido o interferencia es una posibilidad. Esto requiere alguna forma de capa de corrección de errores por adelantado o FEC (Forward Error Correction).



A diferencia de la FEC usada por los operadores de redes de telecomunicaciones que puede ser de propietario (o normalizado por el Instituto de normas de telecomuni-caciones europeo o ETSI (European Telecommunications Standard Institute), que define la transmisión DVB sobre redes SDH y PDH), la corrección de errores por adelantado o FEC usada en broadcast debe ser normalizada de tal forma que los receptores sean capaces de manejarla. La adición de la corrección de errores obvia-mente incrementa la relación de bits en lo que se refiere al transmisor o cable. Des-afortunadamente, una transmisión de datos confiable y económica por radio y cable requiere más que la serialización de los datos. Los sistemas prácticos requieren la codificación de canal.

10.2 Remultiplexión Es una tarea compleja debido a que un Remultiplexor tiene que dar como salida un stream de bits que fue ensamblado con partes de otros. Los datos requeridos de una entrada dada de stream de transporte pueden ser seleccionados con referencia a la Tabla de asociación de programa y a las Tablas de mapa de programa que revelarán las PIDs de los programas requeridos. Es posible que la misma PID se haya usado en dos streams de transportes de entrada, las PIDs de uno o más streams elementales pueden haber cambiado. Los encabezadores de paquete deben transferir la referencia del reloj de programa o PCR (Program Clock Reference) que permitirá que el Decoder final recreé un reloj de 27 MHz. Ya que la posición de los paquetes que contengan la PCR puede ser diferente en la nueva multiplexión, el Remultiplexor podría necesitar editar los valores de PCR para reflejar su nueva posición en el eje del tiempo. La Tablas de mapa de programa y las Tablas de asociación de programa necesitarán editarse para reflejar la nueva estructura del stream de transporte como lo harán las Tablas de acceso condicional o CAT (Conditional Access Tables). Si la suma de las relaciones de bit del stream del programa seleccionado es menor que la relación de bits de la salida, el Remultiplexor creara paquetes de relleno con PIDs adecuadas; sin embargo, si los streams de transporte vienen de Multiplexores estadísticos, es posible que la relación de bits instantánea del nuevo stream de transporte exceda la capaci-dad del canal. Esta condición puede ocurrir si muchos programas seleccionados en diferentes streams de transporte simultáneamente contienen una entropía alta. En ese caso la única solución es recomprimir y crear coeficientes nuevos más cortos en uno o más Streams de bits para reducir la relación de bits.

10.3 Servicio de Información o SI (Information Service) A futuro, la distribución digital implicará que habrá un gran número de programas, teletexto y otros servicios disponibles para los espectadores y estos podrán extender-se a un buen número de diferentes streams de transporte. Tanto el espectador como el Decoder integrado al receptor o IRD (Integrated Receiver Decoder) necesitarán ayuda para desplegar lo que esté disponible y entregar el servicio seleccionado. Esta capacidad requiere de metadata más allá de las capacidades del MPEG-PSI (Pro-gram Specific Information. Información específica del programa) y es referida como DVB-SI (Service Information. Servicio de Información). El DVB-SI es considerado para que incluya al NIT, que es opcional para los streams de transporte MPEG. El DVB-SI está encajado en el stream de transporte como paquetes de transporte adicionales con PIDs únicas y transporta información técnica para IRDs. El DVB-SI

también contiene información de la Guía electrónica de programas o EPG (Electronic Program Guide) como la naturaleza de un programa, duración y el canal en el que puede ser localizado y los países en los cuales está disponible. También se pueden calificar los programas de tal forma que se pueda ejercer un control paterno. El DVB-SI debe incluir las siguientes tablas además de la MPEG-PSI: ► Tabla de información de red o NIT (Network Information Table). Información en

un stream de transporte que describe muchos streams de transporte. La NIT con-tiene información relacionada con la organización física del múltiplex, streams de transporte transmitidos a través de una red dada y las características de la misma red. Los streams de transporte son identificados por la combinación de una ID original de red y una ID de stream de transporte en la NIT.

► Tabla de descripción de servicio o SDT (Service Description Table). Cada servicio en un stream de transporte de DVB puede tener un descriptor de servicio y esos descriptores están ensamblados en la tabla de descripción de servicio. Un servi-cio puede ser televisión, radio o teletexto. El descriptor de servicio incluye el nom-bre del proveedor del servicio

► Tabla de información de evento o EIT (Event Information Table). La EIT es una tabla para DVB que contiene los nombres de programa, tiempos de ini-cio, duración, etc.

► Tabla de hora u fecha o TDT (Time and Date Table). La TDT es una tabla que encaja una hora de UTC y el estampado del tiempo en el stream de transporte.

La DVB-SI también define otras tablas opcionales incluyendo: Tabla de asociación de bouquet o BAT (Bouquet Association Table), Tabla de status actual o RST (Running Status Table), Tabla de corrimiento de tiempo o TOT (Time Offset Table) y la Tabla de relleno o ST (Stuffing Table). Tanto ATSC como DVB, usan la Tabla de sección privada de MPEG-2 para definir tablas nuevas. Este juego de nuevas tablas obligatorias definidas por ATSC en la A/65A es parte del protocolo de programa e información del sistema o PSIO (Program and system information protocol). El PSIP de ATSC debe incluir las siguientes tablas además de la MPEG-PSI: ► Tabla de canal virtual terrestre o TVCT (Terrestrial Virtual Channel Table) define el

mínimo de programas MPEG-2 encajados en el stream de transporte en el cual es transportado el TVCT.

► Tabla de guía maestra o MGT (Master Guide Table) define el tipo, identificadores de paquete y versiones de todas las tablas PSIP en el stream de transporte, ex-cepto el de la Tabla de hora de sistema o STT (System Time Table).

► Tabla de región de clasificación o RRT (Rating Region Table) define el sistema de guía paterna para TV referenciado por cualquier descriptor de asesor de conteni-do transportado dentro del stream de transporte.

► Tabla de hora del sistema o STT (System Time Table) define la fecha y hora actuales.

► Tabla de información de eventos o EIT-n (Event Information Table) define las primeras cuatro tablas e información de eventos (EIT-0, EIT-1, EIT-2 y EIT-3) que describen 12 horas de eventos (programas de TV), cada uno con una cobertura de 3 horas e incluyen todos los canales virtuales enlistados en la TVCT.



10.4 Corrección de errores La corrección de errores es necesaria porque las condiciones en trayecto-rias de transmisión grandes no pueden ser controladas. En algunos siste-mas, la detección de errores es suficiente porque puede ser usada para pedir una retransmisión. Claro que esta aproximación no funcionará con señales en tiempo real como la televisión. En lugar de lo anterior se usa la FEC en la que se adicionan suficientes bits extra, llamados redundancia, a los datos para permitirle al Decoder ejecutar correcciones en tiempo real. La FEC usada en sistemas modernos usualmente está basada en los códigos de Reed-Solomon o (R-S). Una discusión completa de esto está fuera del alcance de este libro. Brevemente, los códigos R-S adicionan redundancia a los datos para hacer una palabra de código tal que cuando cada símbolo se use como término en un mínimo de dos ecuaciones simul-táneas, la suma (o síndrome) siempre sea cero si no hay errores. Esta condición de cero se obtiene sin importar los datos y facilita el chequeo de errores. En streams de transporte, los paquetes siempre son de 188 bytes de largo antes de adicionar los datos de corrección de error. La adición de los 16 bytes de redundancia R-S, producirá una longitud de paquete de 204 bytes (en la práctica, los streams de transporte pueden usar paquetes de 204 bytes aún cuando no esté presente la FEC. El uso de 16 bytes de relleno evita el “reclocking” del stream cuando se adicione o borre la FEC) En el caso de que el síndrome no sea cero, la resolución de las ecuaciones simultáneas dará como resultado dos valores necesarios para la corrección de errores; la localización del error y su naturaleza; sin embargo, si el tamaño del error excede la mitad de la cantidad de la redundancia adicio-nada, el error no podrá ser corregido. Desafortunadamente en canales de transmisión típicos, la calidad de la señal es estadística. Esto significa que mientras que bits simples pueden estar en error debido al ruido, en caso de un gran número de bits, conocido como “burst”, se pueden corromper todos. Esta corrupción puede deberse a un rayo o a interferencia por equi-po eléctrico. No resulta económico proteger cada palabra de código contra estos “bursts” porque no ocurren lo suficientemente seguido. La solución es usar una técnica conocida como “interpolación”. La Figura 10.2 muestra que, cuando se usa la interpolación, los datos de fuente son codificados con FEC pero antes de la transmisión son enviados a un Buffer en RAM. En la Figura 10-3 se muestra una técnica posible en la que los datos entran a la RAM en filas y luego se leen en columnas. Después de esto los datos reordenados son transmitidos. Al momento de la recepción los datos son regresados a su orden original o se “desinterpolan” usando una segunda RAM. El resultado del proceso de interpolado es que un “burst” de errores en el canal después de la desinterpolación se convertirá en un gran número de errores de símbolo simples que son corregibles más fácilmente. Cuando un error de burst alcanza el tamaño máximo corregible, el sistema es vulnerable a errores de bits aleatorios que hacen que las palabras de

código sean incorregibles. El uso de un código interno aplicado después de la interpolación y corregido antes de la desinterpolación puede evitar que entren errores aleatorios a la memoria de desinterpolación. Como muestra la Figura 10-3, cuando se usa esa aproximación con una estructura interpolada de bloque, el resultado es un código producto, La Figura 10-4 muestra que la interpolación también puede ser convolucional en la que el arreglo de los datos sea compartida aplicando un retraso diferente a cada fila. La interpolación cruzado o convolucional tiene la ventaja de que se necesita menos memoria para interpolar o desinterpolar.

►Figura 10-2

►Figura 10-3

►Figura 10-4



► Figure 10-5 10.5 Codificación de canal

Los datos binarios no son adecuados para la transmisión por muchas razones. Las corridas de bits idénticas hacen que el DC se corra y falte el reloj de bits. No hay control del espectro y el ancho de banda requerido es demasiado grande. En la práctica, los sistemas de radio y cable requieren un esquema de modulación llamado código de canal. Los esquemas de modulación digital se discuten en la Sección 9. La Figura 10-5 muestra la aplicación de esos principios para un modulador 64QAM. En los esque-mas que se describieron antes, el espectro de la señal transmitida depen-de de la señal. Algunas partes del espectro pueden contener energía alta y provocan interferencias a otros servicios mientras que otras partes del espectro pueden contener poca energía y ser susceptibles de interferen-

cia. En la práctica se necesita la aleatorización para descorrelacionar el espectro transmitido del contenido de datos. La Figura 10-6 muestra que cuando se usa la aleatorización o la dispersión de energía se adiciona una secuencia pseudo aleatoria a los datos seriales antes de que entren al modulador. El resultado es que el espectro transmitido es similar al ruido con estadísticas relativamente estacionarias. Claramente se deberá substraer una secuencia idéntica y síncrona en el receptor como se mues-tra. La aleatorización no se puede aplicar a los patrones de sincronía o podrían no ser detectados.

► Figure 10-6



► Figure 10-7 10.6 Codificación interna El código interno de un sistema de FEC está diseñado para evitar los errores aleatorios al reducir la potencia del esquema de interpolación. Un código interno adecuado puede evitar esos errores dando un incremento aparente a la SNR de la transmisión. En la codificación Trellis, que puede usarse con señalización multi nivel, muchos símbolos de nivel múltiple son asociados a un grupo. La forma de onda que resulta de un grupo particu-lar de símbolos se le llama Un “trellis”. Si cada símbolo puede tener 8 niveles, entonces en tres símbolos puede haber 512 trellises posibles. En la codificación trellis, los datos son codificados en tal forma que solo ciertas formas de onda de trellis representen datos válidos. Si solo 64 de los trellises representan datos libres de errores, entonces dos bits de datos por símbolo pueden enviarse en lugar de tres. Los bits restantes es una forma de redundancia ya que otros trellises aparte de los 64 correctos deben deberse a errores. Si un trellis es recibido en el cual el nivel de uno de los símbolos sea ambiguo debido al ruido, la ambigüedad puede ser resuelta ya que el nivel correcto debe ser el que da como resultado un

trellis válido. Esta técnica es conocida como máxima decodificación pro-bable. Los 64 trellises válidos deben hacerse tan diferentes como sea posible para hacer que el sistema siga funcionando con una relación señal a ruido más pobre. Si el Coder trellis provoca un error, el código externo lo corregirá. En la DVB, se puede usar la codificación convolucional Viterbi. La Figura 10-7 muestra que después del interpolado los datos son enviados al registro de corrimiento. El contenido de este produce dos salidas que representan diferentes chequeos de paridad de los datos de entrada para que los errores de bit puedan ser corregidos. Claramente habrán dos bits de salida por cada bit de entrada; de aquí, el Coder mostrado es descrito como Coder de ½ relación. Cualquier relación entre 1/1 y 1/2 seguirá permitiendo que los datos originales se transmitan pero la cantidad de redundancia variará. A la falla en la transmisión de la salida de ½ comple-ta se llama “puncturing” (perforación) y permite que se obtenga cualquier balance requerido entre la relación de bits y la potencia de corrección.



► Figure 10-8 ► Figure 10-9 10.7 Transmitiendo dígitos La Figura 10-8 muestra los elementos de un transmisor digital de ATSC. El Servicio de información que describe la transmisión se adiciona al Stream de transporte. Este stream es aleatorizado antes de enrutarlo a un Coder de corrección de error R-S externo que adiciona redundancia a los datos. Un proceso de interpolado convolucional reordena entonces los datos para que los datos adyacentes en el stream de transporte ya no lo sean en la transmisión. Un Coder trellis interno se usará entonces para producir una señal en niveles múltiples para el modulador de banda lateral vestigial o VSB (Vestigial Side Band) La figura 10-9 muestra un transmisor de DVB-T. La información de servi-cio se adiciona como antes, después de la etapa de aleatorización para la dispersión de la energía. Antes de la interpolación se adiciona el chequeo R-S externo de símbolos. Después de la interpolación, el proceso interno

de codificación tiene lugar y los datos codificados se envían a un Modula-dor COFDM. A la salida del modulador se le aplicará un proceso de “up convert” para producir la salida de RF. En el receptor, el reloj de bits se extrae y usa para controlar los tiempos de todo el sistema. La codificación de canal se invierte para obtener los datos en bruto más los errores de transmisión. La codificación interna corrige los errores aleatorios y puede identificar los errores más largos para ayudarle al Coder externo después de la desinterpolación. La aleato-rización se remueve y el resultado es el stream de transporte original. El receptor debe identificar la PAT, el servicio de información o SI (Service Information) y la PMT al que la PAT apunta para poder decirle al auditorio que está disponible en el stream de transporte y que el programa selec-cionado pueda ser localizado en el múltiplex.



Sección 11 – Transmisión de datos En la secciones previas se checaron las bases de un stream de transporte MPEG-2 y su aplicación principal: transportar streams de audio y video comprimidos en una forma similar a las transmisiones analógicas conven-cionales; sin embargo, una de las ventajas principales de un stream de transporte MPEG-2 es que puede transportar datos así como video y audio. Aunque los sistemas de televisión analógicos puedan y transmitan datos, el ancho de banda máximo para estos está severamente limitado comparado con los anchos de banda posibles para los streams de trans-porte. Esta Sección proporcionará una vista general de los diferentes métodos proporcionados por MPEG-2 y las variantes regionales (DVB, ATSC y ARIB (Association of Radio Industries and Businesses. Asociación de industrias y negocios de radio) para encapsular datos dentro de un stream de transporte. La siguiente Sección, entonces, revisará como son presen-tados los datos al espectador en el set top box (que no cae estrictamente dentro del alcance de MPEG-2).

11.1 Aplicaciones Hay muchos tipos diferentes de aplicaciones para la transmisión de datos en un stream de transporte y cada tipo de aplicación puede requerir diferentes tipos de datos con diferentes requerimientos de temporaliza-ción. Por ejemplo, el tipo de datos involucrado con enviar tráfico por Internet es muy diferentes del necesario para proporcionar una actualiza-ción de firmware para una set top box. Una actualización que no sea en tiempo real de la información de precios tiene requerimientos de temporalización muy diferentes que una aplica-ción de cuestionario en la que las respuestas y preguntas deben ser enviadas con una sincronización muy cercana al audio y video. MPEG-2 proporciona una gran variedad de técnicas diferentes para enviar datos. La elección de la técnica es un compromiso entre la optimización del ancho de banda (y de aquí del costo de proporcionar el servicio) al tiempo que llena los requerimientos de temporalización de la aplicación. El tipo de aplicaciones puede agruparse en forma aproximada por sus requerimientos de tiempo real y el nivel de interactividad como se describe en las siguientes secciones.

11.1.1 Datos relacionados con los programas La especificación base de MPEG-2 no tiene ninguna provisión para un EPG que de información acerca de los canales de TV o los programas individuales que se están transportando en el stream de transporte. Las variantes regionales ATSC, DVB y ARIB han usado la sintaxis de la Tabla privada de MPEG-2 como la de la EIT para proporcionar datos adicionales acerca de los programas. Se requiere que esas tablas se transmitan a intervalos regulares y que den tiempos de inicio, sinopsis y otra informa-ción acerca de los programas y servicios; sin embargo, aún este nivel de información podría no ser suficiente y por tanto hay un buen número de EPGs de propietario que extienden la cantidad de información disponible y también proporciona funciones como la búsqueda mejorada, canales favoritos y otros servicios aumentados. Esos EPGs mejorados usualmente residen en forma permanente en la set top box y usan una combinación de la Tabla de información estándar y de los formatos de datos de propie-tario. Usualmente esta clase de información de programa no es crítica en tiempo y por tanto se usan técnicas baratas de baja relación de datos. En muchos casos los datos son diseñados de tal forma que se puedan alma-cenar temporalmente en la set top box para que aparezca como disponi-ble inmediatamente al usuario aún si el tiempo total real de transmisión es relativamente grande.

11.1.2 Datos de oportunidad Raramente es posible utilizar el ancho de banda completo de un stream de transporte con streams de audio y video no solo por la necesidad de manejar las restricciones complejas de la remultiplexión o la inserción de la tabla. Los sistemas de datos de oportunidad usan esta capacidad extra reemplazando algunos paquetes nulos con datos útiles; sin embargo, el ancho de banda de estos datos no se puede garantizar y puede ser pe-queña de aquí que solo pueda ser usada por aplicaciones sin las restric-ciones de tiempo real. Algunas aplicaciones que usan esta clase da datos pueden ser transfe-rencias de archivos como listas de precios o la distribución de datos del nivel de acciones vía satélite a todas las localidades de una compañía. La única restricción es que la transferencia debe tener lugar durante la noche y por tanto usar un ancho de banda corto y por tanto se pueden usar servicios de datos de oportunidad baratos.



11.1.3 Datos de red Una aplicación muy común es usar simplemente el stream de transporte de broadcast como portadora de datos de red. En el más simple de los casos, un enlace de satélite proporcionaría una interconexión de muy alto ancho de banda entre dos compañías geográficamente separadas. Este enlace de red puede ser usada para transportar virtualmente cualquier tipo de protocolo de red; sin embargo, el uso actual más común es para descargas de Internet de alta velocidad usando solo el protocolo IP. En este escenario se usa una conexión de Internet de baja velocidad para enviar instrucciones y requisiciones de página a un servidor de Internet; sin embargo, el servidor de Internet enrutará entonces cualquier dato pedido a través del enlace satelital a velocidades mucho mayores que las posibles para una conexión de banda ancha promedio o de ISDN. Una variante de esta aplicación se usa cuando solo está disponible un canal de “slow back”. En este caso, por ejemplo, los datos relacionados con el programa de TV actual pueden ser entregados “on demand” con la señal transmitida sin que el auditorio se de cuenta que se esta accesando un sitio de Internet.

11.1.4 TV mejorada En una aplicación de TV mejorada no hay canal de “back” (respuesta) y por tanto todos los datos requeridos se deberán enviar en el stream de transporte que se esta transmitiendo. Aunque esta imposición obviamente restringe el diseño y rango de una aplicación aún es posible producir un rango muy amplio de juegos, cuestionarios e infomerciales en los que el auditorio podría no darse cuenta que toda la interacción es solo con la TV. Este es especialmente el caso con material pregrabado en el que es relativamente directo sincronizar los “pop-ups” de datos como las pregun-tas y respuestas de los cuestionarios con el audio/video.

11.1.5 TV interactiva LA diferencia clave entre la TV mejorada y la interactiva es que esta tiene un canal de respuesta para enviar o recibir datos altamente personaliza-dos. Esto incrementa grandemente el rango de aplicaciones que se pue-den soportar, incluyendo la capacidad de proporcionar una interacción en tiempo real con otras personas, como es el caso de los juegos multi-jugador o las votaciones así como retroalimentación realmente personali-zada. Una extensión más de esto es cuando una conexión de Internet de alta velocidad se combina con un canal de respuesta real. Esto ofrece una integración transparente de los datos personalizados con la transmisión de televisión además que también permite un VOD real de programación u otro material.

11.2 Encapsulamiento del contenido La primera etapa en una transmisión de datos es encapsularlos en una forma útil para su transmisión en un stream de transporte. Hay una amplia variedad de tipos diferentes de datos y por tanto las normas MPEG-2 proporcionan un buen número de diferentes métodos de encapsulamiento. Las varias normas específicas para cada país como DVB y ATSC han mejorado aún más las opciones básicas de MPEG-2 para llenar los reque-rimientos regionales pero todo eso constituye el núcleo de las normas MPEG-2.

11.2.1 Encapsulado de datos MPEG

11.2.1.1 Canalización de datos La canalización de datos se usa para la distribución asíncrona simple de los datos a un set top box determinado en la red. Su principal aplicación es enviar datos de propietario en sistemas cerrados en los que el set box al que se le van a enviar ha sido pre programado para buscar datos específicos en ciertas PIDs. Los datos son transportados directamente en el payload o carga útil de los paquetes TS de MPEG-2 TS sin ninguna información de temporalización. Una aplicación típica sería una actualiza-ción nocturna de los niveles de “stock” de un producto a todos los puntos de venta de una región.

11.2.1.2 Streaming de datos El streaming de datos se usa para la distribución punto a punto de datos en forma asíncrona, síncrona o sincronizada. Los datos son transportados como paquetes PES con un método similar al de los servicios de video y audio, De hecho, el audio y video son ejemplos realmente específicos de un servicio de streaming de datos síncronos. Ya que los paquetes PES son señalizados en las Tablas de servicios de información o SI (Service Information), y pueden transportar información de temporalización, esta aproximación será más flexible que la canalización de datos pero en la práctica se usa en una forma similar en sistemas cerrados de propietario.



11.2.1.3 DSMCC - Digital Storage Medium Command and Control (Instrucción y control del medio de almacenamiento digital) La especificación DSM-CC de MPEG-2 (ISO/IEC 13818-6) proporciona más formas de transmitir datos en las secciones de una Tabla privada estándar de MPEG-2. Originalmente fue diseñada como una forma de respaldar la distribución de VOD de material de programa en una red con un stream de transporte. El protocolo se ha extendido para ser capaz de manejar tanto la distribución “on-demand” (usando el paradigma MPE) así como la distribución periódica (usando el paradigma del carrusel) de datos en redes múltiples de proveedores

11.2.1.4 MPE – Multi-protocol Encapsulation (Encapsulado con proto-colos múltiples) El encapsulado con protocolos múltiples o MPE permite que un datagra-ma de cualquier protocolo de comunicación se transmita en la Sección de una Tabla de DSM-CC a través de un stream de transporte. Un datagra-ma es una estructura lógica que contiene toda la información que define los datos; es decir, su tamaño y contenido, donde deben ir y como llegar ahí. La aplicación más común es el tráfico de Internet donde los datagramas de TCP/IP llevan información acerca de las direcciones lógicas (IP) de la fuente y el destino (target) así como del Control de acceso a la media o la dirección de MAC (Media Access Control) (una dirección de red única) del target; sin embargo, el MPE respalda casi todos los tipos de protocolo de red y ciertamente no está restringido a solo los datos de TCP/IP.

11.2.1.5 Carruseles Los carruseles están diseñados para la transmisión periódica de informa-ción en un stream de transporte. Aunque el contenido de un carrusel puede cambiarse como respuesta a una requisición de un usuario de target, es más usual que se repita regularmente el carrusel sin importar que haya o no usuarios pendientes del contenido o de que se necesiten datos en ese momento. Un target que necesita un ítem de datos específi-co se espera que aguarde hasta que se retransmita.

Hay dos tipos diferentes de carruseles: los de datos y los de objetos y las principales diferencias entre ellos es que: ► Los carruseles de datos solo contienen módulos de datos de contenido no

especificado; depende del target saber que hacer con los datos que recibe.

► Los carruseles de objeto contienen objetos de datos identificables como

imágenes, archivos de texto o archivos ejecutables de aplicaciones y con-

tienen un listado de directorio de todos los objetos en el carrusel.

Los carruseles de datos frecuentemente se usan para descargar software de sistema nuevo a un set top box mientras que un objeto de carrusel se usa para servicios de compra, EPGs y para enviar aplicaciones y juegos. En ambos tipos de carrusel, los ítems se repiten a intervalos periódicos; sin embargo, los objetos de carrusel hacen que sea más sencillo variar la relación de repetición de objetos individuales. Por ejemplo, el EPG para las próximas horas puede repetirse con bastante más frecuencia que el que se verá el siguiente mes. Las relaciones de repetición para objetos puede ser una decisión comercial hecha por el proveedor del servicio para maximizar la utilización del ancho de banda. Ambos tipos de carrusel están basados en las extensiones DSM-CC para la especificación de MPEG-2 ISO13818-6, con extensiones especificas para los sistemas DVB, ARIB y ATSC.



► Figure 11-1 11.2.1.6 Carruseles de datos Un carrusel de datos no contiene ningún ítem de datos individual o estruc-tura de directorio sino que es una pieza monolítica simple de datos. De-penderá del usuario de target saber que son los datos y que hacer con ellos. La estructura se muestra en la Figura 11-1. Un ítem simple completo de datos es definido como un “módulo”. Los módulos de transmisión son divididos en uno o más bloques. Cada bloque se enviará como una Sec-ción en el “payload” de un mensaje de descarga de bloque de datos o DDB (DownloadDataBlock), que sigue la sintaxis de la tabla privada definida por MPEG. Los mensajes DDB pueden ser enviados en cualquier orden o con cualquier periodicidad de aquí que se necesite un mecanismo para identificar que DDBs pertenecen a que módulos. Un mensaje de DownloadInfoIndication o DII (Indicación de información de descarga) se usa para enlazar juntos los DDBs a un módulo. La infor-mación para más de un módulo puede estar en un mensaje de DII simple; “esto forma un grupo”. Usualmente un grupo contendrá módulos de datos relacionados lógicamente. Si hay más módulos relacionados que puedan agruparse juntos en un mensaje de DII simple entonces se puede formar un súper grupo de

mensajes de DII múltiples. Estos son referenciados por un mensaje de DownloadServerInitiate o DSI (Iniciar descarga de servidor). Un carrusel de datos de una capa contiene un pequeño número de módu-los referenciados en un DII simple. Un carrusel de datos de dos capas contiene mensajes DSI que hacen referencia a uno o más mensajes de DII. Pueden ser más pequeños o grandes que un carrusel sencillo. Un uso típico de un carrusel de dos capas sería para respaldar lenguajes múltiples. Un grupo puede transportar el ejecutable en un módulo junto con texto en inglés en un segundo módulo. El segundo grupo puede llevar solo un módulo simple con solo texto en francés ahorrándose el “over-head” de repetir el módulo de aplicación.



► Figure 11-2 11.2.1.7 Carruseles de objetos Los objetos de carrusel se usan para transmitir ítems individualmente identificables de datos identificados de un servidor a un receptor. Esos ítems son llamados objetos y pueden ser imágenes, archivos de texto, programas, un indicador de PID de un video, un listado de directorio o salida (gateway) de servicio de lo que está disponible en el carrusel. Los objetos relacionados agrupados se envían juntos como una forma de carrusel sencillo desde un dominio de servicio. Los objetos se pueden enviar tan frecuentemente como se requiera y diferentes objetos pueden tener relaciones de repetición muy diferentes. Una característica clave de los objetos de carrusel es que todos los obje-tos se envían usando el paradigma de BIOP (Broadcast inter-ORB proto-col. Protocolo de transmisión inter-ORB). Los desarrolladores de software convencional han estado usando el ORB (Object Request Brokerage. Corretaje de requisición de objetos) por muchos años. El BIOP extiende el sistema básico para respaldar la identificación y uso de los objetos en un ambiente de broadcast en diferentes redes de diferentes proveedores de servicio.

En esencia, un BIOP es un método para intercambiar información acerca de un objeto que se está transmitiendo en el carrusel. El BIOP puede contener el objeto o simplemente puede proporcionar un indicador al objeto. El BIOP también puede indicar como usar el objeto, incluyendo proporcionar un enlace a donde descargar el software de aplicación necesario para usar el objeto. Los objetos de carrusel son similares a los carruseles de datos en tanto que los grupos de objetos se combinan para formar módulos. La metodo-logía del carrusel de datos básicos será entonces usada para transmitir esos datos usando bloques, módulos y DIIs. La diferencia principal es que el DSI se usa para apuntar directamente al objeto de directorio de la salida (gateway) de servicio que podrá entonces usarse para encontrar todos los otros objetos en el carrusel. Este arreglo se muestra en la Figura 11.2.



► Figure 11-3 11.2.1.8 Como se transmiten los objetos de los carruseles Una explicación completa está más allá de los alcances de este documen-to; la siguiente descripción es una vista general breve y muy simplificada de ese proceso (vea también la Figura 11-3). Los objetos directorio, archivo y stream se envían con el mismo método que para los carruseles de datos, es decir, en módulos divididos en blo-ques. Serán enviados como secciones en el “payload de un DownloadDa-taBlock o DDB (Bloque de datos de descarga). Un mensaje de DownloadServerInitiate o DSI (Iniciar descarga de servi-dor) contiene la localización de un objeto de directorio especial llamado “salida (gateway) de servicio”. Los mensajes de DSI son referidos en el SI y por tanto formaran el punto de inicio para desarrollar lo que es un objeto de carrusel específico. El DSI referencia el DownloadInfoIndication o DII (Indicación de información de descarga) que referencia el DDB que con-tiene el módulo en el que se envía el objeto de salida (gateway) de servi-cio. Los objetos son referenciados en un objeto de directorio usando las IORs (inter-operable object references. Referencias de objeto interoperable). Estos contienen toda la información necesaria para accesar un objeto en el mismo dominio del servicio u otro carrusel de objeto (incluyendo los transportados en otros streams de transporte)

El nombre dado a la estructura en el IOR que describe la localización de un objeto es llamado “perfil de cuerpo” que viene en dos sabores: BIOP profile body (Perfil de cuerpo BIOP) – Usado solo para objetos dentro de este dominio de servicio. Lite Options Profile Body (Perfil de cuerpo de opciones ligeras) – Usado para objetos en otros servidores o streams de transporte. Un IOR puede contener más de un perfil de cuerpo si el objeto está dis-ponible en más de un carrusel y el set top box puede elegir el más fá-cil/rápido de accesar. Se usan “taps” para resolver el problema de que las PIDs usadas para transmitir DIIs, DDBs y streams de video/audio no son conocidas hasta el momento inmediato antes de la transmisión. Dentro del carrusel, todas las referencias a las PIDs solo se hacen en términos de un tap; las asociacio-nes entre un tap y una PID real se hacen en el SI. Esto simplifica basta-mente la remultiplexión de los streams en diferentes redes.



11.2.1.9 Sincronización de datos MPEG-2 Existe la necesidad de que la transmisión de datos esté sincronizada en alguna forma siendo programas lo que se transmite. No es práctico en realidad usar la distribución en tiempo real de un dato como método de sincronización excepto en aplicaciones en tiempo real que no sean críti-cas como la actualización de marcadores en eventos deportivos en los que unos pocos segundos o más de error no tiene significado práctico; sin embargo, aún un segundo o dos pueden tener un impacto muy grande en, por ejemplo, programas de preguntas en los que revelar las respuestas demasiado antes puede tener consecuencias serias. MPEG-2 proporciona diferentes mecanismos de temporalización para diferentes tipos de encapsulamiento de datos. La canalización de datos y el MPE no respaldan ninguna forma de mecanismo de temporalización aparte de la distribución casi en tiempo real de los datos. El streaming de datos de paquetes PES pueden contener estampados de tiempo de presentación o PTS (Presentation Time Stamp) y posiblemente decodificación de los estampados de tiempo o DTS (Decoding Time Stamp) de los estampados de tiempo para la sincronización con el reloj de sistema derivado de los valores de PCR en el stream. El mecanismo es exactamente el mismo para la sincronización y decodificación de audio o video. Los carruseles de datos MPEG-2 no tienen información de temporaliza-ción; sin embargo, los carruseles de objetos pueden contener un objeto especial llamado “un evento stream” que contiene información de tempo-ralización relacionada con el tiempo de reproducción normal o NPT (Nor-mal Play Time) de un programa de televisión individual. El NPT no es el mismo que la PCR ya que el reloj del NPT se puede detener, por ejemplo, durante un corte comercial. En otras palabras, el NPT de un programa puede permanecer en total sincronización con la línea de tiempo del programa sin importar de cuando se transmita o como se divida en fun-ción a los cortes comerciales.

11.2.2 Encapsulado de datos DVB DVB ha adoptado los métodos de encapsulado de la norma MPEG-2 con solo variaciones menores, principalmente para remover posibles ambi-güedades que emergen de las especificaciones originales (EN 301 192). Estas incluyen la especificación de un formato de MPE ligeramente dife-rente y restricciones impuestas al máximo tamaño de paquete de datos PES. DVB también ha tomado la responsabilidad de asegurar que no puedan haber ambigüedades entre los servicios de datos que usan IORs proporcionando la localización única de las IDs de la red y la del servidor. DVB también ha definido dos formatos de streaming de datos PES para el subtitulado y el teletexto en DVB y tiene un formato normalizado para usar los carruseles de datos para transmitir actualizaciones de firmware al set top box (STB). El DVB también ha definido un número de descriptores de datos y tablas adicionales que se discuten más abajo en las secciones de señalización y anuncios. La más útil de esas adiciones es la capacidad de usar un descriptor para proporcionar una mascarilla simple para las direc-ciones de MAC en un datagrama MPE. Esto permite un respaldo simple para servicios estrechos, multi o de transmisión MPE.

11.2.3 Encapsulado de datos ATSC A/90 La especificación ATSC A/90 fue escrita hace muchos años después que el sistema DVB e incluye algunas diferencias significativas con las normas de DVB y MPEG-2. Primero, la A/90 no usa carruseles de objeto y el sistema CORBA/IOR menos, sino que usa una tabla separada, la Tabla de recursos de red o NRT (Network Resources Table), para proporcionar la información de conexión que enlaza un dato referenciado con su locali-zación real. Aparte de una dudosa simplificación de la operación del sistema también habilita el soporte directo para las URLs de Internet que no son soportadas por DVB o MPEG. El mecanismo es mostrado en la Figura 11-4. En segundo lugar, la A/90 solo usa carruseles de datos que efectivamente contengan solo un objeto simple. El formato del carrusel de datos se ha extendido para incluir en forma opcional una adaptación de un encabezador de DSM-CC que puede contener un PTS para habilitar la distribución de datos síncronos. El concepto de MPEG de NPT dentro de un programa no es soportado. A/90 también define tipos de datos adicio-nales incluyendo su propia versión de MPE de DSM-CC así como permitir que a los datos de IP se les haga un streaming usando el formato PES. También soporta una amplia variedad de modelos de temporalización para diferentes tipos de datos aparte del DVB.



► Figure 11-4 11.2.4 Encapsulado de datos de ARIB La norma japonesa ARIB fue definida a partir de la norma A/90 y es dudosamente el más simple de todos los sistemas. No respalda la canali-zación de datos o los carruseles de objetos. En lugar de eso usa el forma-to de carruseles de datos para enviar una o más entidades imponiendo una estructura de directorio específica al contenido del carrusel de datos. El ARIB no permite referencias a ninguna entidad que no esté referida en el PMT y por tanto no tiene necesidad de CORBA (Common Object Re-quest Broker Architecture. Arquitectura de intermediario de requisición de objetos comunes) ni de enlaces de tipo NRT.

11.3 Transmisión de contenidos de datos Los servicios de datos primero son encapsulados de acuerdo con la norma nacional o internacional relevante y luego transmitidos a través de un stream de transporte a un STB; sin embargo, con el fin de usar un servicio de datos, el STB primero debe saber que existe un servicio de

datos y cuando estará disponible (“anunciarlo”). En segundo lugar enton-ces deberá ser posible encontrar e identificar las varias componentes del servicio de datos (“señalización”) cuando se esté trasmitiendo en realidad. MPEG-2 solo define la PAT y la PMT por lo que todos los anuncios y señalizaciones solo podrán hacerse por la inspección del tipo de stream elemental y algunos descriptores muy básicos. Aunque útiles hay un gran número de limitaciones para solo usar la PAT y PMT, no solo que el agendado de los servicios de datos o eventos no es posible. DVB y ATSC han definido tablas adicionales que incrementan significativamente la cantidad de información proporcionada acerca de cualquier servicio de datos presente. Note que en todos los casos las PIDs que transmiten datos deben ser señalizadas como presentes con una entrada en por lo menos un PMT.



11.3.1 Anuncio de DVB La DVB considera que los servicios de datos están asociados con un evento individual (por ejemplo, un programa simple de preguntas) o son parte de un servicio como un canal de deportes. De hecho, se apegan al paradigma de MPEG-2 en el que un servicio de datos es lógicamente indistinguible de un stream de audio o video convencional. Por consiguiente, simplemente ha definido un número de descriptores adicionales que son colocados en el EIT o la tabla SDT que anuncia que un servicio de datos o eventos estará disponible. La localización real de los servicios de datos y componentes serán entonces señalizados usando las técnicas que se describen a continuación. La única nueva tabla es la Tabla de información de la aplicación que es definida por el uso con solo los servicios MHP. Esta contiene una lista de todas las aplicaciones dentro de un carrusel, un indicador a su clase de “boot” y opcionalmente permite que las aplicaciones se inicien automáti-camente o se cierren al cambiar el canal.

11.3.2 Anuncio de ATSC En contraste con la DVB, la especificación A/90 trata los eventos de datos y servicios completamente por separado de los servicios de audio y video y ha adicionado un número de tablas para soportar ese paradigma. Estas tablas son la Tabla de servicios de datos o DST (Data Services Table), que enlista los servicios de datos que se están enviando y la Tabla de eventos de datos o DET (Data Event Table). La DET es exactamente análoga a la EIT para la información de agendado convencional del pro-grama y usa una sintaxis idéntica. Una tercera tabla, la de servicios a largo plazo es similar a la DET pero proporciona información de agendado a largo plazo, más allá de los 16 días máximos proporcionado por la DET.

11.4 Presentación de contenido La etapa final de la transmisión de datos es correr la aplicación en el STB y presentar la información al espectador. Se debe hacer notar que un stream de transporte es completamente agnóstico al contenido real que esté transportando, asumiendo que, por supuesto, esté encapsulado con el protocolo correcto para video, audio o datos. En otras palabras, la siguiente sección casi está completamente desvinculada de las normas de transmisión de datos de MPEG-2, DVB o ATSC como aplicaciones y los datos son distribuidos por el stream de transporte a utilizar por el STB.

11.4.1 Set Top Box intermediario (Middleware) En algunos casos, como el de los datos de Internet, el ambiente en el que los datos se van a usar es auto definido o relativamente no tiene impor-tancia; sin embargo, en la mayoría de los casos, como en los juegos y aplicaciones es crítico que los datos de la aplicación estén construidos de tal forma que corran adecuadamente en el STB de target. En la mayoría de los casos, el STB tendrá una interfase de programa de aplicación o API (Application Program Interface) que correr y que conecta las llamadas de función de alto nivel de la aplicación a los controladores del software que controlan el hardware real en el STB y enlaza los datos en el stream de transporte. Esta capa de software que está entre la aplicación y los con-troladores es conocida como intermediaria o de “middleware.” Sin embargo hay una gran variedad de STB en uso en todo el mundo. Su desempeño y características corren desde cajas muy básicas que solo podrán decodificar y desplegar una imagen básica de calidad estándar con las unidades más modernas con poderosas capacidades de proce-samiento. Algunas unidades modernas tienen integrados de gráficos de alto desempeño y corren sistemas operativos completos como Linux o Windows, están equipados con disco duro para la grabación de progra-mas, tienen DVD ROMs para la reproducción de DVDs y pueden correr paquetes de programas convencionales como el Office de Microsoft o Star Office. Una gráfica simple diseñada para el despliegue en una caja nueva de alto desempeño podría ser que no se pueda desplegar en una unidad más antigua. Los desarrolladores de aplicaciones podrían tener que escribir programas completamente diferentes usando diferentes lenguajes de programación para cada tipo de set top box, middleware y sistema opera-tivo, algo claramente ineficiente y que incrementa los costos de desarro-llo. Ha habido un buen número de intentos de normalizar la cajas o cuando menos su funcionalidad mínima en la que la funcionalidad de la caja claramente es definida y controlada por las empresas de broadcast en una forma muy cerrada. Otra aproximación ha sido tomada por compañías que proporcionan una solución completa ofreciendo un middleware junto con las herramientas de desarrollo de aplicaciones para desarrollar los programas adecuados. Esos sistemas están más abiertos en tanto que el middleware puede ser licenciado para correr en una variedad de diferentes set top boxes con diferente desempeño o características en tanto que llenan las funcionali-dades básicas requeridas.



Un esquema de transmisión de datos de propietario y un servicio interacti-vo de “jardín cercado” han sido usados ampliamente como sistema inter-activo proporcionando una interactividad real a través del canal de res-puesta. Otras ofertas de compañías también se han usado ampliamente en Europa y las aplicaciones pueden ser distribuidas usando objetos de carrusel estándar aunque hay muchos otros sistemas de propietario. Una norma más abierta es un ambiente de aplicación definido por el MHEG (Multimedia Hypermedia Experts Group. Grupo de expertos de hipermedia multimedia). Una variante particular de esto, MHEG-5, está optimizada para aplicaciones de baja memoria y desempeño y algunos set top boxes en particular. MHEG-5 ha tenido cierto éxito, notablemente en Inglaterra donde se le usa para transmisiones terrestres a STBs. La tendencia actual es hacia la normalización en middleware abierto con una API de programación claramente definida. Esta tiene el beneficio de que el consumidor puede elegir de entre una amplia variedad de set top boxes mientras que le permite a los desarrolladores de aplicaciones reusar el código. Recientemente ha emergido un número de candidatos para una norma global, incluyendo la plataforma de multimedia para el hogar o MHP (Multimedia Home Platform) de la DVB. En USA el Foro de mejoramiento de la televisión avanzada o ATVEF (Advanced Television Enhancement Forum) y el ambiente de software de TV digital o DASE (Digital TV Application Software Environment) son las normas abiertas líderes.

11.4.2 Plataforma DVB de multimedia para el hogar o MHP (Multime-dia Home Platform) La plataforma multimedia para el hogar o (Multimedia Home Platform) define una API de gran amplitud con muchos perfiles y niveles diferentes para permitir diferentes STB de diferentes desempeños, costos y servi-cios. La TV mejorada e interactiva (con canales de respuesta) son sopor-tadas y también proporcionan soporte para conexiones a Internet que de otra forma no serían soportados directamente por otras normas de DVB. Las aplicaciones de MHP son distribuidas usando carruseles de objeto estándar de DVB y anunciadas usando la tabla AIT descrita antes. Esto permite que las aplicaciones se auto inicialicen, se pongan en pausa o se detengan y que los recursos sean puestos en caché en forma explícita

con el fin de acelerar los tiempos de inicio de las aplicaciones. La norma MHP está basada en tecnología Java y comprende un juego de APIs derivadas de normas existentes como JavaTV, HAVI (home audio video interoperability. Interoperatibilidad de audio y video en el hogar) y DAVIC (Digital Audio Visual Council. Consejo audiovisual digital). Las aplicaciones pueden ser de Java o basadas en HTML y hay un núme-ro de kits de desarrollo de software MHP disponible de diferentes provee-dores. Las aplicaciones tendrán que someterse a una prueba de confor-midad y estar electrónicamente firmadas para asegurar tanto la interope-ratibilidad como la seguridad del sistema. El logo de MHP también está protegido y los STBs deberán pasar por un proceso de conformidad antes de que puedan ser vendidos con el logo. Las pruebas de interoperatibilidad regular se han llevado a cabo durante los últimos dos años para asegurar que todas las aplicaciones de MHP puedan corren en todas las set top boxes MHP de una gran variedad de fabricantes líder. MHP es la norma de facto en Europa y sus servicios oficialmente iniciaron en Finlandia en Agosto del 2001. Hay un gran núme-ro de servicios de prueba actualmente transmitiéndose en Europa. Ale-mania también usará MHP a partir de mediados de 2002 y otros países harán lo mismo dentro de los siguientes pocos años después. Sin embar-go, MHP no es solo una norma Europea ya que ha sido adoptada en todo el mundo. Por ejemplo, es obligatoria en Corea del Sur para la transmisión de datos vía satélite y en Australia para la transmisión terrestre. En febre-ro de 2002 la organización de plataformas de aplicaciones abiertas para cable o OCAP (Open Cable Applications Platform) de Estados Unidos adoptó la MHP como la norma para transmisión de cable digital america-na. Se espera que muchos otros países y organizaciones adopten el MHP en corto plazo. El impacto global de la MHP no debe ser subestimado. Los líderes actua-les del mercado de servicios de TV interactiva se han comprometido a proporcionar un plug-in MHP para usarlo en su propio middleware de propietario durante 2002, abriendo efectivamente todas sus ser top boxes de propietario a un mercado global. Con algunos países comprometidos con la MHP en toda Europa ya hay un mercado potencial de casi un billón de espectadores que auguran un buen futuro a esta norma abierta.



11.4.3 ATVEF DASE Algunas veces se dice que la diferencia entre ATVEF (Advanced Television Enhancement Forum. Foro de mejoramiento de la television avanzada) y DASE (DigitalTV application software environment. Ambiente de software de aplicación de la television digital) es que el primero reco-mienda el uso de HTML pero permite el uso de Java, mientras que el segundo recomienda Java y permite HTML; sin embargo, hay otras dife-rencias fundamentales. La especificación ATVEF fue escrita por un grupo formado por fabricantes de varias industrias con el fin de definir una funcionalidad normalizada que debe ser proporcionada con el fin de permitir que el contenido interactivo corra en set top boxes, receptores basados en PC y TVs interactivas. La especificación de contenido mejorado o ECS (Enhanced Content Specifi-cation) fue el resultado. La ATVEF ECS define HTML como fundamento para crear contenido de TV interactiva aunque también se permite JavaScript. También se requie-re otras funcionalidades básicas como el uso de gráficas en formato de red portátil (.png) como formato de intercambio de imágenes estándar. ATVEF, por tanto, tiene muchas cosas substancialmente en común con el diseño de páginas de Internet con obvios beneficios para los desarrollado-res de aplicaciones. Una de las fortalezas de ATVEF es que el mecanismo de transporte no está completamente definido o se asume por la norma. Es perfectamente capaz de correr esquemas de transmisión analógicos o digitales, con o sin contenido de video. Esto se logra definiendo un formato de contenido independiente del transporte y por el uso de IP como vínculo de referen-cia. Cualquier esquema de transmisión que use IP, por tanto, podrá usar-se. Esto ha permitido que el ATVEF corra en esquemas NTSC así como en streams de transporte MPEG y proporciona un mecanismo simple para una trayectoria de regreso. El ATVEF se está usando en USA en sistemas de televisión tanto analógica como digital.

11.4.4 DASE En contraste, DASE es una especificación de middleware mucho más compleja que fue desarrollada por el ATSC en USA. Ya que el ATSC también desarrolló la norma de transmisión de datos A/90 la especifica-ción DASE proporciona un vínculo al esquema de transmisión A/90 ade-más de que define la API en la que un aplicación DASE correrá. La norma DASE-1 fue desarrollada como una norma candidata a principios de 2002. DASE incorpora un esquema de señalización y un esquema de anuncios así como el contenido de los datos de aplicación en sí, que son llamados datos de esencia. Se permiten dos tipos de datos de esencia junto con el ambiente y funcionalidad que pueden usar: ► Datos de esencia declarativos basados en el lenguaje de marcado de texto

y scripts .xdml y .xml.

► Datos de esencia procedurales basados en javatv xlets.

Un receptor DASE proporciona un motor para manejar ambos tipos de datos de esencia junto con funcionalidades de núcleo común como los codecs .jpeg o .png que son compartidos entre los dos sistemas. DASE también proporciona enlaces directos al contenido de audio y video que se está transmitiendo y define un número de formatos gráficos de pantalla para desplegar contenido interactivo, incluyendo resoluciones de HDTV. Las aplicaciones se pueden inicializar, activar, suspender o desinicializar en una forma similar al paradigma del ciclo de vida de una aplicación MHP. Los recursos se pueden poner en el caché como se requiera. Aunque DASE tiene todo el apoyo de ATSC detrás, es un contendiente relativamente tardío en este campo y por tanto aún no ha sido adoptado ampliamente.



Sección 12 – Prueba de MPEG La capacidad de analizar streams de transporte existentes para checar su conformidad es esencial pero esta habilidad debe ser complementada por una habilidad de crear streams de transporte que se sepa que se apegan a las normas.

12.1 Requerimientos para las pruebas Aunque la tecnología de MPEG difiere dramáticamente de la tecnología que le precede, los requerimientos de prueba son básicamente los mis-mos. En base a las operaciones, el usuario quiere tener un chequeo simple y regular que asegure que todo está bien. En el caso de una falla, la localización de esta necesita ser establecida rápidamente. Para el diseño de equipo, la naturaleza de los problemas necesita ser explorada con algún detalle. Como con las señales de prueba, la aproximación es combinar la generación de señales válidas conocidas para su inserción en un sistema con la capacidad de administrar señales en varios puntos. Una de las características de MPEG que la aparta del equipo de transmi-sión de video tradicional es la existencia de capas múltiples de informa-ción en las que se espera que cada una de ellas sea transparente para las que están debajo. Es muy importante ser capaces de establecer en que capa reside una falla para evitar búsquedas infructuosas. Por ejemplo, si el monitor de imagen de un Decoder MPEG está mostrando defectos visibles, estos podrían deberse a un buen número de posibilidades. Quizá el Encoder esté dando problemas y el stream de transporte esté entre-gando fielmente la información con fallas. Por otro lado, el Encoder podría estar bien pero la capa de transporte podría estar corrompiendo los datos. En DVB, hay aún más capas como las de dispersión de energía, correc-ción de errores e interpolación. Tal complejidad requerirá una aproxima-ción estructurada para encontrar las fallas usando las herramientas ade-cuadas. La discusión del análisis de protocolo de los datos comprimidos en este “Primer” podría ayudar al usuario a derivar esa aproximación. Leer la discusión de otro aspecto importante de las pruebas para televisión comprimida, “Valoración de la calidad de imagen”, también podría ser útil. Esta última discusión se encuentra en la publicación “A Guide to Video Measurements for Compressed Television Systems.” (Una guía para las mediciones de video para sistemas de televisión comprimidos)

12.2 Análisis de un stream de transporte Un stream de transporte MPEG tiene que ser una estructura extremada-mente compleja pero un analizador como el AD953 puede dividir la estruc-tura en una forma lógica de tal forma que el usuario pueda observar cualquier detalle requerido. Muchos tipos generales de análisis pueden llevarse a cabo en tiempo real en un stream de transporte en vivo; estos incluyen los despliegues de la jerarquía de los programas en el stream de transporte y de la proporción de la relación de bits del stream asignado a cada stream.

Un análisis más detallado solo es posible si parte del stream de transporte es grabado de tal forma que pueda ser dividido en partes posteriormente. Esta técnica es conocida como pruebas de tiempo diferido y pueden usarse, por ejemplo, para examinar el contenido de un estampado de tiempo. Cuando se usan las pruebas de tiempo diferido, el analizador del stream de transporte de MPEG estará actuando como un analizador lógico que proporciona herramientas de interpretación de datos específicas para MPEG. Como con todos los analizadores lógicos, un mecanismo de disparo en tiempo real se requerirá para determinar el tiempo o las condi-ciones bajo las cuales la captura tendrá lugar. La Figura 12-1 muestra que el analizador contiene una sección de tiempo real, una sección de alma-cenamiento y una sección diferida. En el análisis en tiempo real, solo la sección de tiempo real opera y se necesitará que una fuente de señal esté conectada. Para la captura se usa una sección en tiempo real para deter-minar cuando disparar la captura. El analizador incluye herramientas conocidas como filtros que permiten que se aplique el análisis selectivo antes o después de la captura. Una vez que la captura está completa, la sección diferida puede operar sobre los datos capturados y ya no será necesaria la señal de entrada. Hay una buena analogía con el osciloscopio de almacenaje que puede desplegar la entrada de tiempo real directamente o salvarla para estudiar-la después.

► Figura 12-1



► Figura 12-2

12.3 Vista jerárquica Cuando se analiza un stream de transporte que no sea familiar, la vista jerárquica es un excelente punto de inicio porque habilita una vista gráfica de cada componente en el stream. La Figura 12-2 muestra un ejemplo de despliego jerárquico como el proporcionado por el MTX100 de Tektronix. Comenzando en la parte superior izquierda del stream de transporte completo, el stream se divide y se presenta un icono para cada compo-nente del stream. La tabla 12-1 muestra los diferentes íconos que la vista jerárquica usa y su significado. El usuario puede ver muy fácilmente cuantos streams de programa están presentes y el contenido de audio y video de cada uno. Cada icono representa la capa superior de un número de análisis más bajo y capas de información El analizador crea la vista jerárquica usando la PAT y la PMT en los datos de PSI en el stream de transporte. Las PIDs de esas tablas se despliegan debajo de cada icono. Los datos de las PAT y PMT son fundamentales para la operación de cualquier Demultiplexor o Decoder; si el analizador no puede desplegar una vista jerárquica o despliega una vista la cual obviamente esté mal, el stream de transporte a prueba tendrá un error de PAT/PMT. Es poco probable que el demás equipo sea capaz de interpre-tar el stream.

► Figura 12-3

► Figura 12-4 La habilidad de un Demux o Decoder de “amarrarse” a un stream de transporte dependerá de la frecuencia con la que los datos de PSI son enviados. La opción de relación PSI/SI mostrada en la Figura 12-3 des-plegará la frecuencia de inserción del sistema de información. La informa-ción de PSI/SI deberá también ser consistente con el contenido real en el stream de bits. Por ejemplo, si una PID dada es referida en una PMT debe ser posible encontrar PIDs de ese valor en el stream de bits. La función de chequeo de consistencia hace esa comparación. La Figura 12-4 muestra una consistencia de error de un stream incluyendo dos paquetes no referenciados.



► Tabla 12-1. Iconos de la vista jerárquica

Icono Tipo de elemento Paquetes de transporte múltiplex. Este icono representa a todos (paquetes de transporte de 188- y 204- bytes) los que forman el stream. Si visualiza el stream de transporte como un tren, este icono representa cada carro en el tren sin importar su configuración (por ejemplo, vagón, furgón o silo) y lo que contiene.

Paquetes de transporte de una PID particular (ID de programa). Otros elementos (tablas, relojes, paquetes PES) que son la “payload” contenida dentro de los paquetes de transporte o se construyen a partir de la payload de muchos paquetes de transporte que tienen la misma PID. El número de PID aparece debajo del icono. En la vista jerárquica el icono a la derecha de este representa la “payload” de los paquetes con esta PID.

Paquetes de transporte que contienen relojes de PCR independientes. La PID aparece debajo del icono.

Secciones PAT (Program Association Table. Tabla de asociación de programa). Siempre está contenida en los paquetes de transporte de PID 0

Secciones PMT (Program Map Table. Tabla de mapa de programa)

Secciones NIT (Network Information Table. Tabla de información de red). Proporciona acceso a las tablas SI a través de la instrucción PSI/SI del menú de selección. También se usa para las secciones privadas. Cuando la opción DVB está seleccionada (en el menú de Opciones) este icono también puede representar las secciones SDT, BAT, EIT y TDT.

PES (Packetized Elementary Stream. Stream elemental paquetizado). Este icono representa todos los paquetes que, juntos, contienen un stream elemental dado. Los paquetes PES elementales son ensamblados a partir de “payloads” de muchos paquetes de transporte.

Stream elemental de video

Stream elemental de audio

Stream elemental de datos

Secciones ECM (Entitlement Control Message. Mensaje de control de derechos)

Secciones EMM (Entitlement Management Message. Mensaje de administración de derechos)



► Figura 12-5 Una tabla de localización de MUX puede desplegar gráficamente las proporciones del stream de transporte asignado a cada PID o programa. La Figura 12-5 muestra un ejemplo de un despliegue de la tabla de locali-zación de un MUX. La vista jerárquica y la Tabla de localización de MUX muestran el número de elementos en el stream de transporte y la propor-ción del ancho de banda asignado.

12.4 Vista interpretada Como una alternativa para checar datos específicos en lugares no especi-ficados es posible analizar datos no especificados en lugares específicos incluso en los paquetes del stream de transporte, las tablas o los paque-tes PES. Este análisis es conocido como vista interpretada porque el analizador hace un análisis (parse) y decodifica los datos y luego desplie-ga su significado. La Figura 12-6 muestra un ejemplo de un paquete de transporte MPEG en vista “hex” así como en vista interpretada. A medida que se cambia el ítem seleccionado, el número de paquete relacionado con el inicio del stream puede ser desplegado. La Figura 12-7 muestra un ejemplo de una PAT en la vista interpretada.

► Figura 12-6 ► Figura 12-7 12.5 Sintaxis y análisis de CRC Para embarcar material de programa, el stream de transporte depende completamente del uso exacto de la sintaxis por parte de los Encoders. Sin ajustes correctos de bits de bandera fija, patrones de sincronía, códi-gos de inicio de paquete y conteos de paquete, un Decoder puede inter-pretar mal el stream de bits. La función de chequeo de sintaxis considera todos los bits que no son material de programa y despliega cualquier discrepancia. Las discrepancias espurias pueden deberse a errores de transmisión, las discrepancias consistentes apuntan a un Encoder o Multiplexor con fallas. La Figura 12-8 muestra un error de sintaxis así como un chequeo de redundancia cíclica (CRC) faltante.



► Figure 12-8 Muchas tablas MPEG tienen adjuntadas “checksums” o CRCs para la detección de errores. El analizador puede recalcular los checksums y compararlos con el checksum original, De nuevo, las inconsistencias espurias de CRC pueden deberse a errores de bits del stream pero los errores consistentes de CRC apuntan a fallas de hardware.

12.6 Filtraje Un stream de transporte contiene una gran cantidad de datos y en condi-ciones reales de falla, es probable que a menos de que exista un proble-ma serio, muchos de los datos son válidos y quizá solo un stream elemen-tal o un programa esté afectado. En ese caso, es más efectivo probar en forma selectiva lo cual es la función del filtraje. Esencialmente, el filtraje le permite al usuario de un analizador ser más selectivo cuando examine un stream de transporte. En lugar de aceptar cada bit, el usuario puede analizar solo aquellas partes de los datos que llenen ciertas condiciones. Una condición que resulta del filtraje de los encabezadores de los paque-tes es que solo los paquetes con una PID dada serán analizados. Esta aproximación hace que resulte sencillo checar la PAT seleccionando PID 0, y de aquí, todos los otros PIDs podrán leerse. Si las PIDs de un stream del que sospechamos se conocen, quizá por ver un despliegue jerárquico, será sencillo seleccionar una PID simple para el análisis.

► Figure 12-9

12.7 Análisis de temporalización Las pruebas descritas checan la presencia de los elementos correctos y la sintaxis del stream de transporte; sin embargo, para desplegar el audio y video correctamente en tiempo real, el stream de transporte también debe entregar una temporalización exacta a los Decoders. Esta tarea puede ser confirmada analizando la PCR y los datos de estampado de tiempo. La transferencia correcta de los datos del reloj de programa es vital por-que estos datos controlan la temporalización completa del proceso de decodificación. El análisis de PCR puede mostrar que, en cada programa, los datos de PCR se envían a una relación suficiente y con suficiente exactitud para cumplir con las normas. Los datos de PCR de un Multiplexor pueden ser precisos, pero al remulti-plexar se pueden poner los paquetes de un programa dado en un lugar diferente en el eje del tiempo, requiriendo que los datos de PCR sean editados por el Remultiplexor. Consecuentemente, es importante probar la PCR para checar las inexactitudes después de que los datos son remulti-plexados. La Figura 12-9 muestra un despliegue de PCR que indica las posiciones a las cuales la PCR se recibió con respecto al reloj promedio. En el si-guiente nivel de despliegue, cada PCR puede ser abierta para desplegar los datos de la PCR como se muestra en la Figura 12-10. Para medir inexactitudes, el analizador predice el valor de la PCR usando las PCRs previas y la relación de bits para producir lo que es llamado la PCR inter-polada. El valor real de la PCR es sustraído de la PCR estimada para dar una estimación de las inexactitudes.



► Figura 12-10 Una aproximación alternativa mostrada en la Figura 12-11 proporciona un despliegue gráfico del intervalo de PCR, jitter, desbalanceo de frecuencia y deriva de la señal que es actualizada en tiempo real. La Figura 12-12 muestra un despliegue de estampado de tiempo para un stream elemental seleccionado. Se muestra ka unidad de acceso, el tiempo de presentación y donde es apropiado, la hora de decodificación. En MPEG, el reordenamiento y el uso de diferentes tipos de imagen provocan un retraso y se requiere un “Buffering” tanto en el Encoder como en el Decoder. Un stream elemental dado debe ser codificado dentro de las restricciones de la disponibilidad del “Buffering” en el decoder. ► Figura 12-12

► Figura 12-11 MPEG define un Decoder modelo llamado T-STD (Transport Stream System target decoder. Decoder de target del sistema de stream de transporte); un Encoder o Multiplexor no debe distorsionar el flujo de datos más allá de la capacidad de “Buffering” del T-STD. El stream de transpor-te contiene los parámetros llamados VBV (Video Buffer Verify. Verificar el Buffer de video) que especifica la cantidad de “Buffering” necesario para un stream elemental dado. El análisis T-STD despliega gráficamente como se ocupa el Buffer para que los sobreflujos y los “underflows” se puedan ver fácilmente. La Figura 12-13 muestra un despliegue de Buffering. ► Figura 12-13



La salida de un Compresor/Multiplexor normal es de uso limitado porque no es determinístico. Si el defecto de un Decoder es visto, no hay garantía de que el mismo defecto sea visto en una repetición de la prueba porque la misma señal de video no dará como resultado el mismo stream de transpor-te. En este caso, un stream de transporte absolutamente repetible es esen-cial para lograr que el defecto se repita para su estudio o rectificación. El jitter del stream de transporte debe estar entre ciertos límites pero un Decoder bien diseñado debe ser capaz de recuperar programas más allá de ese límite con el fin de garantizar una operación confiable. No hay forma de probar esta capaci-dad usando streams de transporte existentes porque, si cumplen con las normas, el Decoder no se estará probando. Si hay una falla, no será repetible y podría no quedar claro si la falla se debió al jitter o algún otro incumplimiento de las normas. La solución es generar un stream de transporte que cumpla con las normas en todos los aspectos y luego adicionar una cantidad controlada de inexactitudes para que estas sean conocidas y por tanto sean la única parte de la señal que no cumpla con las normas. La función de editor del AD953 está diseñada para crear esas señales.

12.8 Pruebas al stream elemental Debido a la naturaleza flexible del stream de bits MPEG, el número de posibilidades y combinaciones que contiene es casi incalculable. Ya que el Encoder no está definido, los fabricantes no están forzados a usar cada posibilidad; de hecho, por razones económicas, esto sería improbable. Este hecho hace que hacer pruebas sea muy difícil porque el hecho de que un Decoder trabaje con un Encoder particular no prueba su conformi-dad con las normas. Ese Decoder podría simplemente no usar los modos que causan que el Decoder falle. Una mayor complicación aparece porque los Encoders no son determinís-ticos y no producirán el mismo stream de bits si se repite la entrada de audio o video. Hay pocas oportunidades de que exista el mismo alinea-miento entre las imágenes I-, P- y B-y los cuadros de video. Si un decoder falla en una prueba dada, podría no hacerlo la siguiente vez que se corra la prueba haciendo difícil la localización de errores. Una falla con un Encoder dado no determina si la falla está en el Encoder o el Decoder. La dificultad de codificación depende fuertemente en la naturaleza del mate-rial de programa y cualquier material dado no necesariamente ejercerá cada parámetro sobre todo el rango de codificación. Para hacer pruebas que tengan resultados significativos, se requieren dos herramientas:

► Una fuente conocida de señales de prueba que cumplan con las normas y

que deliberadamente exploren todo el rango de codificación. Esas señales

deben ser determinísticas para que la falla en un Decoder dé síntomas re-

petibles. Los streams de bits que cumplen con Sarnoff están diseñados pa-

ra ejecutar esta tarea.

► Un analizador de stream elemental que permita checar la conformidad con

las normas de la sintaxis completa de un Encoder.

► Figura 12-14 12.9 Streams de bits que cumplen con Sarnoff ® Esos streams de bits han sido especialmente diseñados por la Corpora-ción Sarnoff ® para probar la conformidad con las normas del Decoder. Estos pueden estar multiplexados en un stream de transporte que alimen-ta un Decoder. No se requiere tener acceso al funcionamiento interno del Decoder. Para evitar la necesidad de un análisis largo de la salida del Decoder, los streams de bits tienen que ser diseñados para crear una imagen plana cuando se completen de tal forma que solo sea necesario conectar un monitor de imagen a la salida del Decoder para verlas. Hay un buen número de esas imágenes simples. La Figura 12-14 muestra la pantalla gris de verificación. El usuario debe examinar la pantalla de verificación para ver las discrepancias que se desplegarán bien contra el campo gris. También hay algunas imágenes de verificación que no son grises. Algunas pruebas no darán como resultado una imagen si hay una falla, esas pruebas despliegan la palabra “VERIFY” en la pantalla cuando se completan. Otras pruebas requieren que el espectador cheque que haya un movimiento suave de un elemento que se mueve por la imagen. Los problemas de temporalización o de orden provocarán un jitter visible. El paquete de pruebas de Sarnoff puede ser usado para checar todos los elementos de la sintaxis MPEG a la vez. En una prueba, el stream de bits comienza solo con imágenes I-, adiciona imágenes P- y luego adiciona imágenes B- para probar si se pueden manejar y reordenar correctamente todos los tipos de imágenes de MPEG. La compatibilidad atrasada con MPEG-1 se puede probar. Otras streams de bit hacen pruebas usando un rango de diferentes estructuras de GOP. Hay pruebas que checan la operación de los vectores de movimiento y hay pruebas que varían el tamaño de las “slices” o la cantidad del relleno.



► Figura 12-15 Además de proporcionar pruebas para el Decoder, los streams Sarnoff también incluyen secuencias que causan que un buen Decoder produzca señales de prueba de video estándar para checar los DACs (digital-to-analog converter. Convertidores digital a analógico), niveles de señal y/o Encoders Y/C. Esas secuencias convierten al Decoder en un generador de patrones de prueba de video capaces de producir señales de video convencionales como placas de zonas, rampas y barras de color.

12.10 Análisis del stream elemental Un stream elemental es la carga útil o “payload” que el stream de trans-porte debe entregar en forma transparente. El stream de transporte lo hará ya sea que el stream elemental cumpla o no con las normas. En otras palabras probar un stream de transporte en conformidad simplemen-te significará checar que esté entregando streams elementales sin cam-bios. Eso no significa que los streams elementales estén bien ensambla-dos para empezar. La estructura o sintaxis del stream elemental es la responsabilidad del Compresor. Por tanto, probar un stream elemental es esencialmente una forma de prueba del Compresor. Se debe hacer notar que un Compresor puede producir una sintaxis que cumpla con las normas y aún así tener una calidad de audio o video pobre; sin embargo, si la sintaxis es incorrec-ta, un Decoder podría no ser capaz de interpretar el stream elemental. Ya que los compresores son algorítmicos más que determinísticos, un stream elemental podría no cumplir con las normas de forma intermitente si algún modo de operación menos común no se está implementado ade-cuadamente.

► Figura 12-16 Ya que los streams de transporte frecuentemente contienen muchos programas que vienen de diferentes Coders, los problemas de stream elemental tienden a estar restringidos a un programa mientras que los problemas del stream de transporte tienden a afectar a todos los progra-mas. Si los problemas son notados con la salida de un Decoder en parti-cular, entonces las pruebas de conformidad con Sarnoff deberán correrse en ese Decoder. Si son satisfactorias, la falla podría estar en la señal de entrada. Si la sintaxis del stream de transporte ya se probó o si otros programas están trabajando sin fallas, entonces se justificará un análisis de stream elemental. El análisis de stream elemental puede iniciar en el nivel superior de la sintaxis y continuar hacia abajo. Los encabezadores de secuencia son muy importantes ya que le dicen al Decoder todos los modos y paráme-tros relevantes usados en la compresión. La sintaxis del stream elemental descrito en las secciones 5.1 y 5.2 se deben usar como guías. La Figura 12-15 muestra un encabezador de secuencia y su extensión desplegada en un AD953. A un nivel más bajo de pruebas, la Figura 12-16 muestra un cuadro B- decodificado junto con los vectores de movimiento sobrepues-tos en la imagen.



12.11 Creando un stream de transporte Siempre que se sospeche de un Decoder es útil ser capaces de generar una señal de prueba de calidad conocida. La Figura 12-17 muestra que un stream de transporte debe incluir el PSI (Program Specific Information. Información específica del programa) como PAT, PMT y NIT para descri-bir uno o más streams de programa. Cada stream de programa debe contener su propio PCR y streams elementales que tengan estampados de tiempo periódicos. Un stream de transporte DVB contendrá información de servicio adicional como BAT, SDT y Tablas EIT. Un editor PSI/SI habilitará la inserción de cualquier combinación que cumpla con las normas de PSI/SI en un stream de prueba de cliente. Claramente, cada ítem requerirá compartir la relación del stream de transporte disponible. El Multiplexor proporciona un medidor de relación para desplegar la relación de bits total utilizada. La parte restante de la relación de bits es usada insertando paquetes de relleno con PIDs que contengan solo “1s” que rechazará el Decoder.

12.12 Generación de inexactitudes PCR El Decoder MPEG tiene que recrear un reloj continuo usando las mues-tras de reloj en los datos PCR para controlar un PLL (phase-locked loop. Lazo de fase cerrada). El lazo necesita filtraje y amortiguamiento de tal forma que el jitter, en el momento de llegada de los datos al PCR, no cause inestabilidad en el reloj. Para probar el desempeño del PLL, se requiere una señal con inexactitud conocida; de otra forma la prueba no tendría sentido. El AD953 puede generar inexactitudes simuladas para ese propósito. Debido a su genera-dor de referencia, el AD953 tiene circuitos de reloj altamente estables y el jitter real a la salida es muy pequeño. Para crear el efecto del jitter, la temporalización de los datos PCR no se cambiará. En lugar de eso, los valores de PCR se modifican de tal forma que el conteo de PCR que contienen es ligeramente diferente del ideal. El valor modificado da como resultado errores de fase en el Decoder que son indistinguibles del jitter real.

► Figure 12-17 La ventaja de esta aproximación es que un jitter de cualquier magnitud se puede adicionar fácilmente a cualquier stream de programa simplemente modificando los datos de PCR y dejando los otros datos intactos. Otros streams de programa en el stream de transporte no necesitan que se les adicione jitter. De hecho, lo mejor podría ser tener un stream de programa estable para usarlo como referencia. Para diferentes pruebas, la base de tiempo puede ser modulada en dife-rentes formas que determine el espectro del error de fase del lazo con el fin de probar el filtraje del lazo. El jitter de onda cuadrada alterna entre valores con los cuales se igualará tarde o temprano. Los valores de jitter senoidal provocan que el error de fase sea una senoidal muestreada. El jitter aleatorio hace que el error de fase sea similar al ruido.



Glosario AAC – Advanced Audio Coding - Codificación avanzada de audio AAU – Audio Access Unit - Unidad de acceso de audio - Ver Access unit (Unidad de acceso) AC-3 – El esquema de compresión de audio inventado por los Laboratorios Dolby y especificados para la norma de televisión digital del ATSC. En el mundo del equipo de consumidor se le llama Dolby Digital. Access Unit - Unidad de acceso – Los datos codificados para una imagen o bloque de sonido y cualquier relleno (valores nulos) que le siguen. A/D – Convertidor analógico a digital. AES – Audio Engineering Society- Sociedad de ingeniería de audio Anchor Frame - Cuadro ancla – Un cuadro de video que se usa para predicción. Los cuadros I- y P- generalmente se usan como cuadros de ancla pero los B- -nunca. ANSI – American National Standards Institute - Instituto de normas nacionales americanas API – Application Program Interface - Interfase de programa de aplicación ARIB – Association of Radio Industries and Businesses - Asociación de negocios e industrias de radio Asynchronous Transfer Mode ATM - Modo de transferencia asíncrono – Un protocolo de señal digital para el eficiente transporte de información con relacio-nes continuas y como ráfagas en redes digitales de banda ancha. El stream digital ATM consiste de paquetes de longitud fija llamada “cells,” (celdas) cada una contiene 53 bytes de 8 bits, un encabezador de 5 bytes y una carga útil o “payload” de 48 bytes de información. ATM – Vea Asynchronous transfer mode - Modo de transferencia asíncrona ATSC – Advanced Television Systems Committee - Comité de sistemas de television avanzada ATVEF – Advanced Television Enhancement Forum - Foro de mejoramiento de la televisión avanzada) AU – Access Unit - Unidad de acceso BAT – Bouquet Association Table - Tabla de asociación de bouquet BER – Bit Error Rate - Relación de errores de bit BFSK – Binary Frequency Shift Keying - “Llaveo” de corrimiento de frecuencia binaria BIOP – Broadcast Inter-ORB Protocol - Protocolo de transmisión Inter-Orb Bit rate - Relación de bit – La relación a la cual el stream de bits comprimido es distribuido del canal a la entrada de un decoder. Block – Bloque – Un bloque es un arreglo de valores de píxel o coeficientes de DCT, usualmente de 8 por 8 representando información de luminancia o cromi-nancia Bouquet – Un grupo de streams de transporte en el que los programas son identificados por la combinación de la ID de la red y la PID (parte de DVB-SI). BPSK – Binary Phase Shift Keying - “Llaveo” de corrimiento de fase binaria

CA - Conditional Access – Información que indica si un programa tiene scram-bling CAT – Conditional Access Table – Tabla de acceso condicional – Paquetes que tienen códigos de PID (vea la Sección 8 – Streams de Transporte) de 1 y que contienen información acerca del sistema de scrambling. Vea ECM y EMM. CD – Compact disc – Disco compacto CELP – Code Excited Linear Predictive – Predictiva lineal excitada por código Channel Code – Código de canal - Una técnica de modulación que convierte datos en bruto en una señal que puede ser grabada o transmitida por radio o cable. CIF – Common Interchange Format – Formato de intercambio común – Un formato de 352x240 pixeles para video conferencias a 30 fps. Closed GOP – GOP Cerrado – Un grupo de imágenes en las que las últimas imágenes no necesitan datos del siguiente GOP para la codificación bidireccio-nal. Los GOP cerrados se usan para hacer un punto de división en un stream de bits. Coefficient – Coeficiente - Un número que especifica la amplitud de una fre-cuencia particular o función de base en una transformada CORBA – Common Object Request Broker Architecture – Arquitectura del intermediario de requisiciones de objeto común COFDM – Coded Orthogonal Frequency Division Multiplex – Multiplexión por división de frecuencia ortogonalmente codificada - Una forma modificada de OFDM. Esquema de modulación digital que usa un número muy grande de portadoras, cada una transportando una relación de datos muy baja. Usada para DVB-T. Compression – Compresión - Reducción del número de bits usados para representar un ítem de datos. CRC – Cyclic Redundancy Check – Chequeo de redundancia cíclica DAC – Digital-to-Analog Converter – Convertidor digital a analógico DASE – DigitalTV Application Software Environment – Ambiente de software de aplicación para TV digital DAVIC – Digital Audio Visual Council – Concejo audio visual digital DCT – Discrete Cosine Transform – Transformada discreta de coseno DDB – DownloadDataBlock – Bloque de datos a descargar DET – Data Event Table – Tabla de evento de datos DFT – Discrete Fourier Transform – Transformada discreta de Fourier DII – DownloadInfoIndication – Indicación de información de descarga Dolby Digital – Vea AC-3 DSI – DownloadServerInitiate – Iniciar descarga del servidor DSMCC – Digital Storage Media Command and Control – Instrucción y control de la media de almacenamiento digital



DST – Data Services Table – Tabla de servicios de datos DTS – Decoding Time Stamp – Decodificación del estampado de tiempo - Parte del encabezador PES que indica cuando se ha decodificado una unidad de acceso. DVB – Digital Video Broadcasting – Transmisión de video digital - General-mente se refiere al consorcio iniciado por los europeos que une a empresarios de broadcast, fabricantes, cuerpos regulatorios y otros que han creado normas para la distribución de televisión digital y servicios de datos incluyendo versiones de DVB-C (cable), DVB-S (satélite) y DVB-T (terrestre). DVB-SI – DVB Service Information – Servicio de información de DVB – Infor-mación transportada en un múltiplex de DVB que describe los contenidos de diferentes multiplexes. Incluye NIT, SDT, EIT, TDT, BAT, RST y ST (vea la Sección 10 – Introducción a DVB y ATSC). DVC – Digital Video Cassette – Cassette de video digital DVD – Digital Versatile Disk or Digital Video Disk – Disco versátil digital o disco de video digital Elementary Stream – Stream elemental. La salida en bruto de un compresor que lleva una señal simple de audio o video. ECM – Entitlement Control Message – Mensaje de control de derechos. Infor-mación de acceso condicional que especifica palabras de control u otros paráme-tros de scrambling específicos del stream ECS – Enhanced Content Specification – Especificación de contenido mejora-do EIT – Event Information Table – Tabla de información de evento – Parte de DVB-SI EMM – Entitlement Management Message – Mensaje de administración de derechos – Información de acceso condicional que especifica un nivel de autori-zación o servicios de Decoders específicos. Se puede direccionar un solo Deco-der individual o un grupo de ellos ENG – Electronic News Gathering – Captura electrónica de noticias – Término usado para describir el uso de la grabación de video en lugar de película para la cobertura de noticias Entropy Coding – Codificación de entropía – Codificación de longitud variable sin pérdidas de la representación digital de una señal para reducir la redundancia EOB – End of Block - Fin de bloque EPG – Electronic Program Guide – Guía electrónica de programas – Una guía de programas distribuida por la transferencia de datos en lugar de un papel impreso. ETSI – European Telecommunication Standard Institute – Instituto de normas europeas de telecomunicaciones FEC – Forward Error Correction – Corrección de errores por adelantado – Sistema en el que se adiciona redundancia al mensaje para que los errores puedan corregirse dinámicamente en el receptor. FGS – Fine Grain Scalability – Escalabilidad de grano fino GOP – Group of Pictures – Grupo de imágenes – En orden de transmisión un GOP inicia con una imagen I- y termina con la última imagen antes de la siguien-te imagen I- .

HAVI – Home Audio Video Interoperability- Interoperabilidad de audio y video en el hogar Huffman coding – Codificación de Huffman – Un tipo de codificación de fuente que usa códigos de diferentes longitudes para representar símbolos que tienen diferente probabilidad de ocurrencia IEC – International Electrotechnical Comisión- Comisión electrotécnica internacional Inter-coding – Intercodificación - Compresión que usa la redundancia ente imágenes sucesivas; también se le conoce como codificación temporal Interleaving – Interpolación - Una técnica usada para la corrección de errores que rompe las ráfagas de errores en muchos errores más pequeños. Intra-coding – Intracodificación – Tipo de compresión que trabaja completamen-te dentro de una imagen; también se le conoce como codificación espacial IOR – Inter-operable Object Reference – Referencia de objeto interoperable IP – Internet Protocol – Protocolo de Internet I-pictures – Intra-coded Pictures – Imágenes intracodificadas IRD – Integrated Receiver Decoder. Receptor-Decodificador integrado. Un receptor de RF combinador con un Decoder MPEG que se usa para adaptar un aparato de TV a las transmisiones digitales ISDB – Integrated Services Data Broadcasting – Sistema de transmission digital desarrollado en Japón ISO – International Organization for Standardization - Organización interna-cional para la normalización ITU – International Telecommunication Union – Unión Internacional de tele-comunicaciones JPEG – Joint Photographic Experts Group – Grupo de expertos en fotografía JTC1 – Joint Technical Committee of the IEC – Reunión técnica del Comité de la IEC JVT – Joint Video Team – Unión del equipo de video Level – Nivel – El tamaño de la imagen de entrada en uso con un perfil dado (ver Sección 2 – Compresión en video) MAC – Media Access Control – Control de acceso de media Macroblock – Macrobloque – El área de la pantalla representada por muchos bloques de DCT de luminancia y diferencia de color que son guiados por un vector de movimiento Masking – Enmascaramiento - Un fenómeno psicoacústico en el que ciertos sonidos no se pueden oír en presencia de otros. MDCT – Modified Discreet Cosine Transform – Transformada discreta de coseno modificada MGT – Master Guide Table – Tabla de guía maestra MHP – Multimedia Home Platform – Plataforma multimedia para el hogar.



Motion Vector – Vector de movimiento - Un par de números que representan el desplazamiento vertical y horizontal de una región de una imagen de referencia para la predicción. MP@HL – Main Profile at High Level – Perfil principal a nivel alto MP@LL – Main Profile at Low Level - Perfil principal a nivel bajo MP@ML – Main Profile at Main Level - Perfil principal a nivel principal MPE – Multi-protocol Encapsulation – Encapsulamiento de protocolos múlti-ples MPEG – Moving Picture Experts Group – Grupo de expertos en imágenes en movimiento. Norma ISO/IEC JTC1/SC29/WG11 y las normas desarrolladas por este grupo. MPEG-LA – MPEG License Agreements – Acuerdos de licencia MPEG NIT – Network Information Table – Tabla de información de red. Información en un stream de transporte que describe muchos streams de transporte. NPT – Normal Play Time – Tiempo normal de reproducción NRT – Network Resources Table – Tabla de recursos de red Null Packets – Paquetes nulos – Paquetes de relleno que no transportan datos pero que son necesarios para mantener una relación de bits constante con una carga útil (payload) variable, Los paquetes nulos siempre tienen una PID de 8191 (todos “1s”). (Vea Sección 8 –Streams de Transporte). OCAP – Open Cable Applications Platform – Plataforma de aplicaciones abiertas de cable OFDM – Orthogonal Frequency Division Multiplexing – Multiplexión por división de frecuencia ortogonal ORB – Object Request Brokerage – Intermediario de requisición de objetos PAL – Phase Alternate Line – Línea de fase alternada PAT – Program Association Table – Tabla de asociación de programa. Datos que aparecen en paquetes y que tienen un código de PID (vea Sección 8 –Streams de Transporte) de cero que el Decoder MPEG usa para determinar que programas existen en un Stream de Transporte. La PAT apunta a la PMT quien, a su vez. apunta al contenido de video, audio y datos de cada programa PCM – Pulse Code Modulation – Modulación de código de pulso – Un término técnico para una forma de onda analógica de fuente, por ejemplo las señales de audio y video, expresadas como muestras periódicas numéricas. PCM es una señal digital sin comprimir. PCR – Program Clock Reference – Referencia de reloj de programa. La muestra del conteo de reloj del Encoder que se envía en el encabezador del programa para sincronizar el reloj del Decoder PES – Packetized Elementary Stream – Stream elemental paquetizado PID – Program Identifier - Identificador de programa– Un código de 13 bits en el encabezador de paquete de transporte, PID 0, indica que el paquete contiene un PAT PID. (Ver Sección 8 – Streams de Transporte) PID 1 indica un paquete que contiene CAT. La PID 8191 (todos “1”) indica paquetes nulos (relleno). Todos los paquetes que pertenecen al mismo stream elemental tienen la misma PID.

PMT – Program Map Tables – Tablas de mapeo de programa. Las tablas en PAT que apuntan al contenido de video, audio y datos de un stream de transporte. Packets – Paquetes. Es un término usado en dos contextos: en los streams de programa, un paquete es una unidad que contiene una o más unidades de presentación; en streams de transporte, un paquete es un quantum de datos pequeño de tamaño fijo. Pixel – Picture element (algunas veces pel) – Elemento de imagen – Es la unidad más pequeña de una imagen, representada por una muestra o un juego de muestras como RGB o YCrCb. Preprocessing – Preprocesamiento – Procesamiento de la señal de video que ocurre antes de la codificación MPEG. La reducción de ruido, downsampling, edición al corte, identificación y pulldown 3:2 son ejemplos de preprocesamiento. Profile – Perfil - Especifica la sintaxis de codificación usada Program Stream – Stream de programa – Un stream de bits que contiene video comprimido, video, audio e información de temporalización. PS – Program Stream – Stream de programa PSI – Program Specific Information - Información que hace el seguimiento de los diferentes programas en un stream de transporte MPEG y en los streams elementales en cada programa. La PSI incluye PAT, PMT, NIT, CAT, ECM y EMM. PSI/SI – Un término general para la combinación de MPEG PSI y DVB-SI. PSIP – Program and System Information Protocol – Protocolo de información de programa y sistema PTS – Presentation Time Stamp – Estampado de tiempo de presentación - El tiempo al cual una unidad de presentación estará disponible para el auditorio. PU – Presentation Unit – Unidad de presentación – Una imagen comprimida o bloque de audio. QAM – Quadrature Amplitude Modulation – Modulación en cuadratura de la amplitud. Un sistema de modulación digital. QCIF – One-quarter-resolution (176x144 pixels) Common Interchange For-mat. Formato común de intercambio a un cuarto de resolución (176x144 pixeles) Vea CIF. QMF – Quadrature Mirror Filter – Filtro de espejo de cuadratura QPSK – Quaternary Phase Shift Keying (también conocido como “Llaveo de corrimiento de fase de cuadratura). “Llaveo” de corrimiento de fase cuaternario. Un sistema de modulación digital particularmente útil para enlaces a satélite. QSIF – One-quarter-resolution Source Input Format - Formato de entrada de fuente a un cuarto de resolución. Vea SIF. Quantization – Cuantización – Un paso de procesamiento que aproxima los valores de la señal asignando un valor de entre un número de valores predefinidos. RLC – Run Length Coding – Codificación de longitud corrida – Un esquema de codificación que cuenta el número de bits similares en lugar de enviarlos indivi-dualmente. RRT – Rating Region Table – Tabla de clasificación de Región RST – Running Status Table – Tabla de estatus de “corriendo”



R-S – Reed-Solomon - Es una función polinomial usada para la DVB por protec-ción. Hasta 8 bytes dentro de cada paquete de transporte. SAOL – Structured Audio Orchestra Language – Lenguaje estructurado de orquesta de audio Scalability – Escalabilidad – Una característica de MPEG-2 que proporciona niveles múltiples de calidad proporcionando capas de datos de video. Las capas múltiples de datos permiten que un Decoder complejo produzca una mejor imagen usando más capas de datos mientras que uno más simple puede seguir produciendo una imagen usando solo la primera capa de datos. SDI – Serial Digital Interface – Interfase digital serial. Norma de interfase de cable coaxial serial diseñado para la producción de señales de video digital SDK – Software Development Kit – Paquete de desarrollo de software SDT – Service Description Table – Tabla de descripción de servicio. Una tabla que enlista los proveedores de cada servicio en un stream de transporte. SDTV – Standard Definition Television – Televisión con definición estándar SI – Vea DVB-SI. SIF – Source Input Format – Formato de fuente de entrada. Una señal de entrada de media resolución usada por MPEG-1. Slice – Una secuencia de macrobloques consecutivos. SMPTE – Society of Motion Picture and Television Engineers – Sociedad de ingenieros de cine y televisión SNR – Signal-to-Noise Ratio – Relación señal a ruido SP@ML – Simple Profile at Main Level - Perfil simple a nivel principal SPTS – Single Program Transport Stream – Stream de transporte de progra-ma simple ST – Stuffing Table – Tabla de relleno STB – Set Top Box. STC – System Time Clock – Reloj de tiempo de sistema. El reloj común usado para codificar audio y video en el mismo programa STT – System Time Table – Tabla de tiempo de sistema Stuffing – Relleno – Datos sin sentido adicionados para mantener constante la relación de bits. Syndrome – Síndrome – Resultado inicial del cálculo de chequeo de errores. Generalmente si el síndrome es cero, entonces se asume que no hay error TCP/IP – Transmission Control Protocol/Internet Protocol – Protocolo de control de transmission/Protocolo de Internet TDAC – Time Domain Aliasing Cancellation – Cancelación del aliasing en el dominio del tiempo. Una técnica de codificación usada en la compresión de audio AC-3. TDT – Time and Date Table – Tabla de fecha y hora. Se usa en DVB-SI. TOT – Time Offset Table – Tabla de disparidad de tiempo

Transport Stream (TS) – Stream de transporte – Multiplexión de muchos streams de programa que son transportados en paquetes. La demultiplexión se logra con diferentes IDs de paquetes o (PIDs). Ver PSI, PAT, PMT y PCR. Truncation – Truncado – Acortamiento de la longitud de palabra de una muestra o coeficiente removiendo los bits de menor orden T-STD – Transport Stream System Target Decoder – Decoder de target del sistema de stream de transporte. Un Decoder que tiene una cierta cantidad de Buffer de memoria que se asume que tomará en cuenta un Encoder TVCT – Terrestrial Virtual Channel Table – Tabla de canal terrestre virtual VAU – Video Access Unit. Unidad de acceso de video. Una imagen comprimida en un stream de programa VBV – Video Buffer Verify – Verificar el Buffer de video VCO – Voltage Controlled Oscillator – Oscilador controlado por voltaje VLC – Variable Length Coding – Codificación de longitud variable. Una técnica de compresión que asigna códigos cortos a valores frecuentes y códigos largos a valores infrecuentes. VOD – Video On Demand – Video en demanda. Un sistema en el cual los programas de television o las películas se transmiten a un solo consumidor cuando lo pide. VSB – Vestigial Sideband Modulation – Modulación de banda lateral vestigial. Un sistema de modulación digital usado por ATSC. Wavelet – Una transformada que usa una función básica que no es de longitud fija pero que crece más a medida que se reduce la frecuencia. Weighting – Ponderación. Un método para cambiar la distribución del ruido debido al truncado por medio de valores de pre multiplicación. Y/C – Luminance and chrominance – Luminancia y crominancia

Contactos de Tektronix: Asociación de Naciones del sureste Asiático / Australasia / Pakistán (65) 6356 3900

Austria +41 52 675 3777 Balcanes, Israel, Sud África y otros países de ISE +41 52 675 3777

Bélgica 07 81 60166 Brasil y Sudamérica 55 (11) 3741-8360

Canadá 1 (800) 661-5625 Europa central, Ucrania y el Báltico +41 52 675 3777

Europa central y Grecia +41 52 675 3777 Dinamarca +45 80 88 1401 Finlandia +41 52 675 3777

Francia y África del Norte +33 (0) 1 69 86 81 81 Alemania +49 (221) 94 77 400

Hong Kong (852) 2585-6688 India (91) 80-22275577 Italia +39 (02) 25086 1

Japón 81 (3) 6714-3010 Luxemburgo +44 (0) 1344 392400

México, América Central y el Caribe 52 (55) 56666-333 Este Medio, Asia y Africa del Norte+41 52 675 3777

Los países bajos 090 02 021797 Noruega 800 16098

República popular de China 86 (10) 6235 1230 Polonia +41 52 675 3777

Portugal 80 08 12370 República de Corea 82 (2) 528-5299

Rusia y CIS 7 095 775 1064 Sudáfrica +27 11 254 8360 España (+34) 901 988 054

Suecia020 08 80371 Suiza +41 52 675 3777

Taiwán 886 (2) 2722-9622 Reino Unido y Eire +44 (0) 1344 392400

USA 1 (800) 426-2200 Para otras áreas contacte a Tektronix, Inc. al: 1 (503) 627-7111

Última actualización Junio 15 2005

Para mayor Información Tektronix mantiene una colección comprensiva y en constante expansión de notas de aplicación, notas técnicas y otros recursos para ayudarles a los ingenieros a trabajar con la tecnología más avanzada. Favor de visitar www.tektronix.com Copyright © 2005, Tektronix, Inc. Todos los derechos reservados. Los productos de Tektronix están protegidos por patentes norteamericanas y extranjeras concedidas y pendientes. La información de esta publicación reemplaza todo el material previamente publicado. Nos reservamos el privilegio de cambiar las especificaciones y precios. TEKTRONIX y TEK son marcas registradas de Tektronix, Inc. Todas los demás nombres referidos son marcas de servicio, marcas de negocio o marcas Registradas por las compañías respectivas

Habilitando la Innovación

Habilitando la innovación - cecyt4.files.wordpress.com · 4.4.1 Documentos de la norma MPEG-4 32...

Documents

Transcript of Habilitando la innovación - cecyt4.files.wordpress.com · 4.4.1 Documentos de la norma MPEG-4 32...