Introducción a la Televisión Digital actual

El consorcio DVB

El proyecto DVB (Digital Video Broadcasting Project) es un consorcio de más de 300 entidades a lo largo de todo el mundo. Entre las mismas tenemos broadcasters, fabricantes de equipos, operadoras de red, desarrolladores de software y entidades reguladoras (entre otras) repartidas a lo largo de más de 35 países.

El proyecto DVB está dedicado al diseño y desarrollo de estándares globales orientados a la transmisión de televisión digital, incluyendo transmisión de datos.

El proyecto DVB desarrolla especificaciones para sistemas de televisión digital. Posteriormente estas especificaciones son presentadas en los diferentes organismos de estandarización internacionales (principalmente ETSI) que a partir de ellas desarrollan sus estándares. Una vez que los estándares son aprobados, se presentan a la comunidad científica internacional para su adopción.

Por lo tanto, el desarrollo de los diferentes estándares DVB es un trabajo dirigido fundamentalmente por las empresas que forman el consorcio DVB.

Una lista completa de las empresas que forman el consorcio puede consultarse en la siguiente pagina web: "http://www.dvb.org/index.php?id=27&il=A".

En consecuencia, el proyecto DVB está completamente orientado a las necesidades del mercado y ésta es seguramente una de las principales razones de su éxito.

DVB se creó en 1992 como una iniciativa estrictamente Europea, pero a día de hoy su extensión es a nivel mundial, encontrándose entre sus miembros entidades de todos los continentes del globo.

En la presente introducción teórica se realizará una breve iniciación a algunos conceptos básicos relacionados con los estándares de transmisión de televisión digital DVB. Los estándares DVB están basados en sistemas MPEG-2, por lo que el estudio de estos últimos se hace imprescindible a la hora de comprender los primeros.

MPEG-2

Para que la televisión digital sea viable el primer paso es contar con algoritmos adecuados de compresión tanto de vídeo como de audio que permitan reducir la velocidad de transmisión necesaria. En segundo lugar, es necesario definir como se va a enviar esta información por el canal de transmisión de manera que los descodificadores MPEG-2 sean capaces de recuperar el vídeo y el audio de uno o varios programas.

Los sistemas MPEG-2 (MPEG-2 systems) definen como se tiene que multiplexar el vídeo y el audio comprimido, además de los posibles datos adicionales, para formar un único flujo de datos que permita ser transmitido o almacenado.

Hay dos tipos de multiplexación especificados por los sistemas MPEG-2. El Tren de Programa (program stream, PS) está formado por la multiplexación de un solo programa  y es utilizado, por ejemplo, por el DVD. Por otro lado, el tren de transporte (transport stream, TS) define como se multiplexan varios programas y es el que utiliza DVB, entre otros. Estas dos multiplexaciones facilitan la inclusión de la PSI (Program Specific Information), que da información de los datos que se multiplexan.

Además, los sistemas MPEG-2 aportan unas referencias temporales para que los datos se representen en el momento adecuado puesto que, por ejemplo, el sonido y las imágenes no viajan en paralelo, pero el usuario final las tiene que percibir en el mismo momento. Además, los sistemas MPEG-2 dan flexibilidad para la inclusión de nuevas sintaxis, añadir información de control de acceso condicional, datos,… En la figura 1 tenemos un ejemplo gráfico.

Figura 1

La normativa MPEG-2 no especifica como se tiene que realizar esta multiplexación ni como protegerla. A título orientativo, sólo mencionar que los dos tipos de multiplexación que se están manejando actualmente son o bien TDM (Multiplexación por División de Tiempo), o bien estadística. La TDM es aquella que siempre asigna un espacio de tiempo concreto y constante a cada componente del program stream.

La multiplexación estadística, a diferencia de la TDM, representa un cambio de mentalidad respeto al conocido hasta ahora. Ahora ya no se asigna un espacio de tiempo determinado y concreto, sino que los diferentes programas se van pasando información de cuánto ancho de banda requieren para la transmisión. Así pues, un programa que necesite mucho podrá beneficiarse de uno que tenga espacio libre y que, de otra manera, se desaprovecharía utilizando bits de relleno (stuffing bits).

En realidad ambas multiplexaciones (TDM y estadística) son multiplexaciones en el dominio del tiempo (en contraposición a las multiplexaciones en frecuencia). La diferencia entre ambas radica en que la multiplexación estadística reserva las ranuras de tiempo de manera dinámica.

Todos los conceptos anteriormente introducidos, serán posteriormente detallados.

2.1. Paquetes MPEG-2

Como ya se ha comentado anteriormente, MPEG-2 dispone de varios sistemas diferentes para la transmisión u almacenamiento de datos, pero todos ellos coinciden en la utilización de paquetes para la realización de esa tarea.

Un paquete es una colección de bits de un mismo tipo (video, audio, datos…). Los paquetes pueden ser de tamaño fijo o variable, en función de la aplicación para la que estén destinados.

Figura 2

De esa forma, los paquetes de tamaño variable serán utilizados para aplicaciones en las que el medio este libre de errores (DVD, CD-ROM, Disco Duro…). Además, la longitud de dichos paquetes podrá llegar a ser muy grande, minimizando el espacio reservado para cabeceras y demás mecanismos de señalización los cuales reducen la eficiencia del sistema.

Los paquetes de longitud fija, normalmente serán de pequeño tamaño y se utilizarán para aplicaciones en las que el medio sea susceptible de introducir errores (por ejemplo en broadcast). Nótese que al tener paquetes de longitud fija y pequeña se simplifica muchísimo la corrección de errores en los mismos, además de reducir el efecto de dichos errores sobre nuestro sistema.

Los paquetes son la llave a la flexibilidad y a la extensibilidad de los sistemas MPEG-2. Un sistema basado en paquetes es flexible, ya que permite una sencillísima multiplexación basada en el tiempo y al mismo tiempo la optimización de nuestros recursos a través de una asignación dinámica de los mismos basada en la prioridad de los diferentes paquetes.

Figura 3

Un sistema basado en paquetes es fácilmente ampliable, por lo que se garantiza la extensibilidad del mismo. Dicha extensibilidad se consigue haciendo que el receptor descarte aquellos paquetes que no es capaz de decodificar. De esa forma, la ampliación de las prestaciones de nuestro sistema no afecta a los receptores antiguos, ya que simplemente descartan lo que desconocen y siguen siendo capaces de decodificar el resto.

Evidentemente, ampliar un sistema implica que los equipos antiguos no serán capaces de percibir dicha ampliación.

Figura 4

2.2. MPEG-2 Elementary Streams (ES)

Los contenidos que transporta un sistema MPEG-2 pueden ser muy variados. Como ejemplo podemos pensar en un DVD, en el cual además de las tramas de vídeo y audio podemos encontrar subtítulos e incluso juegos interactivos. Además, es posible que dispongamos de más de una opción para cada uno de esos contenidos (varias tramas de audio diferentes, subtítulos en distintos idiomas, etc…).

Cada uno de ellos conforman tramas elementales de datos independientes entre si, aunque pueden estar relacionadas de alguna manera. El termino en inglés para definir a dichas tramas es Elementary Stream.

Los Elementary Streams (ES) son los datos tal y como salen del codificador MPEG-2. Los datos que entran al codificador, como por ejemplo las imágenes, se denominan unidades de presentación y los datos comprimidos son las unidades de acceso. En la figura 2 se puede ver la diferencia entre unidades de acceso y unidades de representación en la compresión de una secuencia de vídeo.

Figura 5. Unidad de presentación y unidad de acceso

El resultado de la codificación de una secuencia de vídeo es una sucesión de unidades de acceso. Esto es lo que forma el Video Elementary Stream.

De manera similar, el audio está formado por una sucesión de unidades de acceso que forman el Audio Elementary Stream (figura 6). Cada unidad de acceso contiene unas decenas de milisegundos de audio comprimido.

Figura 6

Como ya hemos comentado más arriba, en los sistemas MPEG-2 no tenemos únicamente Elementary Streams de vídeo o de audio. De esta forma pueden existir datos privados, teletexto, subtítulos, aplicaciones interactivas… y además existen varios tipos diferentes de Elementary Streams de cada uno de esos tipos (vídeo MPEG-1, video MPEG-2, audio MPEG-2, audio AC3…).

2.3. Packetised Elementary Streams (PES) y Secciones MPEG-2

El siguiente punto en el proceso de multiplexación es convertir cada Elementary Stream en un Packetised Elementary Stream (PES). Un paquete PES está formado por cabecera y payload. El payload está formado por los datos cogidos secuencialmente del stream elemental. No hay necesidad de alinear las unidades de acceso y el comienzo de los PES payloads. Es más, una nueva unidad de acceso puede empezar en cualquier punto del payload. A continuación tenemos un ejemplo de como se inserta la información del Elementary Stream dentro de los paquetes PES.

Figura 7. Paso de ES a PES

Los paquetes PES pueden ser de longitud variable hasta un máximo de 64 Kbytes. La estructura de un paquete PES es el que se muestra en la figura 8.

Figura 8. Paquete PES completo

Los primeros 4 bytes de la cabecera forman el código de inicio del paquete PES. Evidentemente, durante todo el paquete PES esta secuencia de bits no se puede repetir, puesto que si no, se podría interpretar como el inicio de un nuevo paquete.

 El campo stream_id permite distinguir paquetes PES de un mismo programa. El estándar MPEG-2 especifica los valores permitidos para este campo, incluyendo 32 para streams elementales de audio y 16 para streams elementales de vídeo.

 Los flags 1 y 2 son bits que indican la presencia o ausencia de campos opcionales en la cabecera. Estos paquetes opcionales dan idea de, por ejemplo, si la información contenida está encriptada, tiene alguna prioridad, trae información de copyright y un campo opcional de control de errores para el paquete PES.

De los mencionados flags, hay dos que son de gran importancia. Son los que están marcados como PTS y DTS en la figura 8. Cuando estos bits están activos indican la presencia del Presentation Time Stamp (PTS) y el Decoding Time Stamp (DTS). Estos serán los elementos que permitirán la correcta sincronización de los diferentes ES de vídeo y audio en recepción.

A continuación está el paquete de longitud de cabecera, que indica cuántos bytes opcionales hay en la cabecera antes de que empiece el primer byte de payload.

Para más detalles relativos a la estructura del paquete PES lo más acertado es recurrir a la propia especificación MPEG-2. En concreto en [1] punto 2.4.3.6.

Sin embargo, los paquetes PES no son la única manera definida en MPEG-2 para la transmisión de datos. En ese sentido también se utilizan, entre otras, las secciones MPEG-2. Más adelante entraremos en detalles acerca de dicha estructura. En este punto simplemente se pretende llamar la atención sobre el hecho de que no todos los Elementary Streams son finalmente introducidos en paquetes PES.

Los paquetes PES son la manera más habitual (en la práctica, prácticamente la única) de transmitir información de vídeo o audio, pero para el resto de datos el encapsulamiento puede ser diferente.

Otra aplicación de los paquetes PES es el encapsulamiento mediante datos privados (PES private data). Los subtítulos o el teletexto son habitualmente encapsulados a través de este método.

2.4. MPEG-2 Transport Stream (TS) y Program Stream

MPEG-2 define dos maneras de construir la trama de datos. Por un lado tenemos el Transport Stream y por otro el Program Stream.

El Transport Stream es la estructura que se define para la transmisión en medios susceptibles de errores. Por lo tanto todas las aplicaciones destinadas a broadcast se realizarán en este formato. El formato de Transport Stream utiliza paquetes de longitud constante, llamados transport packets o paquetes de transporte. El tamaño de estos paquetes es de 188 bytes.

La información de señalización en un Transport Stream se realiza mediante el Program Specific Information (PSI) que se transmite mediante tablas, las cuales son encapsuladas en secciones MPEG-2.

La aplicación más importante del formato Transport Stream es la transmisión de televisión digital en los estándares DVB y ATSC.

El Program Stream es la estructura que define MPEG-2 para el almacenamiento de datos en medios libres de errores, como pueden ser los DVDs, discos duros, CD-ROMs, etc… Un Program Stream está formado por paquetes de longitud variable. Además, estos paquetes tendrán una longitud relativamente grande (por ejemplo, 2.048 bytes). En un Program Stream sólo podemos encontrar datos relativos a un único programa.

En la siguiente figura mostramos esquemáticamente la construcción de ambos formatos.

Figura 9

En la presente introducción nos centraremos únicamente en aplicaciones para broadcast, por lo que a partir de ahora solamente entraremos en detalles referentes a la estructura de Transport Stream.

MPEG-2 Transport Stream (TS)

El Transport Stream (TS) soluciona los problemas críticos presentes en los trenes de programa con respecto a la pérdida de un paquete, puesto que se limita la longitud de estos a 188 bytes. Por ello, su uso está más orientado a la difusión por broadcast. Un Transport Stream dispone de mecanismos de detección de errores, pese a que hace falta añadir todavía métodos de corrección de dichos errores. Además, el Transport Stream permite multiplexar varios programas dentro de un mismo flujo binario de datos.

Se denomina programa, dentro de una trama de transporte, a una agrupación lógica de tramas elementales. La manera más sencilla de comprender este concepto es pensando en un canal de televisión, en el cual tenemos tramas de video, audio, datos, etc… todas esas tramas conforman el programa. En cualquier caso, es conveniente advertir de que no todas las tramas del programa se presentan al mismo tiempo en pantalla (o por los altavoces del televisor). Continuando con el ejemplo anterior, un programa de televisión podría tener varias tramas de video asociadas, pero en un momento dado podríamos estar presentando sólo una de ellas por pantalla.

Al igual que ocurre en cualquier protocolo que divida su complejidad en capas, los paquetes de transporte están formados por una cabecera seguida de una carga o información útil.

Los paquetes PES son divididos entre los payloads de los paquetes de transporte (Figura 10). El proceso de división de paquetes tiene que seguir dos premisas. Una es que el primer byte de cada paquete PES tiene que ser el primero del payload del paquete de transporte. La segunda premisa es que cada paquete de transporte sólo puede traer información de un PES.

Es bastante probable que no haya un número entero de paquetes de transporte para traer todo el PES, con lo cual, nos quedan paquetes sin acabar de llenar. Para que se cumplan las premisas anteriores, existe un campo de adaptación que permite acabar de llenar el paquete. Son los denominados bits de relleno. Su uso se puede minimizar, utilizando longitudes de paquetes PES grandes, puesto que así aseguramos que una gran parte de los paquetes de transporte estén completamente llenos.

Figura 10. Generación de los paquetes TS a partir de los paquetes PES

Los paquetes que resulten de este proceso forman el Transport Stream. No se especifica el orden en qué los paquetes de transporte llegan al multiplexor. Lo único que sí que se especifica es que los paquetes de un mismo PES han de enviarse secuencialmente.

Hay que volver a insistir en el hecho de que no todos lo paquetes de transporte contienen paquetes PES. Por poner un par de ejemplos, la información de programa (PSI) o las aplicaciones interactivas son transmitidas en secciones MPEG-2 que posteriormente se encapsulan en paquetes de transporte. Más adelante entraremos en detalles sobre las anteriores cuestiones.

3.1. MPEG-2 Transport Packet

La multiplexación del transport stream consiste, como se ha dicho, en pequeños paquetes de longitud constante. Un paquete de transporte es siempre de 188 bytes, de los cuales 4 se destinan a una cabecera de inclusión obligatoria tras la que podemos encontrar un campo de adaptación opcional. El resto de bytes, hasta completar los 188, son de información (payload), tal y como se puede apreciar en la figura 11.

Figura 11

El significado de los campos más importantes es el siguiente:

• Sincronismo de byte. Sirve para que el decodificador pueda sincronizarse correctamente con los datos entrantes. Tiene el valor 0x47 y delimita el inicio de un paquete TS. Hace falta mencionar que, al contrario de los paquetes PES, este valor de sincronización puede darse a cualesquiera de los 187 bytes restantes.

• Indicador de error de transmisión. Este bit se pone activo cuando se detecta un error en la transmisión.

• Indicador de comienzo de payload. Indica si en la cabecera del payload hay un PES.

• PID. Como ya se ha mencionado, los paquetes de TS pueden traer información de programas diferentes, además de datos para la reconstrucción de la información. Aparece un campo de 13 bits que se denomina PID (identificador de paquete) que permite la distinción de paquetes de diferentes elementary streams. De los 213 valores posibles, hay 17 reservados para funciones especiales. Esto permite 8175 valores que son asignables a todos los otros ES que forman el TS. El multiplexor tiene que garantizar que cada ES tenga un único PID. La normativa MPEG no especifica que valores de PID se tienen que dar a los ES (a excepción de los 17 mencionados).

• Control de scrambling. Indica si hay o no datos encriptados en el payload.

• Control del campo de adaptación. Indica si la cabecera tiene campo de adaptación.

• Contador de continuidad. El codificador lo incrementa en 1 cada vez que envía un paquete de la misma fuente. Esto permite que el decodificador sea capaz de deducir si ha habido una pérdida (o ganancia incluso) de un paquete de transporte y evitar errores que no se podrían deducir de otra manera.

A continuación se detallen algunos de los campos existentes dentro de un campo de adaptación:

• Longitud del campo de adaptación. Indica la longitud de la cabecera extra.

• Indicador de discontinuidad. Está en el PCR y en el contador de continuidad. Se utiliza para evitar pérdidas de información producidas por un salto en el codificador.

• PCR. Es la referencia del reloj del programa.

• Stuffing bytes. Son bytes de relleno para conseguir una trama de 188 bytes de información en el supuesto de que no hubiera información suficiente para llenar el paquete.

• Splice countdown. Indicador que permite una conmutación limpia entre un TS y otro TS.

3.2. Sincronización Audio Vídeo

En la señal tradicional de televisión la información de sincronización de la señal se transmitía directamente en la misma (pulsos de sincronismo, burst…). Sin embargo la sincronización de la señal digital de televisión requiere de ciertos mecanismos más complejos.

Lo primero que tenemos que comprender es que la señal de video que transmitimos, al estar codificada en MPEG-2 no utiliza el mismo espacio para cada una de sus imágenes. Esto hace que algunas sean decodificadas en menor tiempo que otras. Además, en una sola trama de transporte podemos tener varios programas diferentes (y dentro de cada uno de ellos varios ES diferentes), por lo que es imposible ajustar el tiempo de presentación de cada uno de los paquetes en función de su tiempo de llegada.

Figura 12

Ese es el motivo de que dentro de las cabeceras de los PES de vídeo y audio introduzcamos los campos PTS y DTS. Los PTS (Presentation Time Stamps) nos darán información del instante en que un determinado paquetes PES ha de ser presentado en el terminal de televisión. Los DTS (Decoding Time Stamps) nos informan del instante en que el decodificador debe decodificar el paquete PES para poder presentarlo a tiempo. Los DTSs solo se incluyen en los PES de vídeo.

Mediante estos dos campos en las cabeceras PES resolvemos nuestro problema de transmitir el momento de presentación y decodificación de los diferentes paquetes, pero todavía nos falta tener la referencia del reloj mediante el cual fueron codificados.

Para resolver este último punto, el codificador MPEG-2 debe introducir referencias del reloj de programa mediante el que esta codificando el audio y el video. Estas referencias se denominan Program Clock Refererences (PCR). Los PCR son campos de 42 bits que el codificador MPEG-2 introduce en los paquetes de transporte (dentro de los campos opcionales de la cabecera de adaptación). MPEG-2 obliga a la introducción de PCRs al menos 10 veces por segundo, pero el estándar DVB es todavía más estricto y reduce a 40 ms el tiempo máximo entre PCRs.

Figura 13

Hay que resaltar, que el reloj de programa es único para cada programa de nuestra trama MPEG-2, pero puede variar entre los diferentes programas.

Por lo tanto, el decodificar engancha su reloj de programa mediante los PCRs introducidos por el codificador, de tal forma que luego es capaz de decodificar y presentar los diferentes paquetes PES en el momento adecuado. Dicho momento lo obtiene a partir de los DTS y PTS.

Figura 14

3.3. Program Specific Information (PSI)

Una trama de transporte MPEG-2 está formada por varios programas diferentes.

Un programa MPEG-2 está compuesto por diferentes Elementary Streams.

El decodificador MPEG-2, además de ser capaz de decodificar cada uno de los Elementary Streams que conforman un programa ha de ser capaz de encontrarlos dentro de una trama de transporte. El Program Specific Information (PSI) es lo que permite que el decodificador realice esa tarea.

Toda la señalización necesaria para la correcta recepción de la trama de transporte se da mediante tablas de información de servicio (Service Information Tables en inglés). Estas tablas se introducen en la propia trama de transporte divididas en secciones MPEG-2 y embutidas en paquetes de transporte. Estas tablas de señalización conforman Elementary Streams, tal y como lo hacen las tramas de video y audio. Por lo tanto, cada una viajará en paquetes de transporte con un PID único para cada Transport Stream.

Sin embargo, el mecanismo mediante el que dichos Elementary Streams se introducen en los paquetes de transporte es diferente al usado para las tramas que habíamos visto hasta este momento. Una tabla de PSI no se introduce en un paquete PES antes de encapsularse en paquetes de transporte. Las tablas se introducen en secciones MPEG-2, las cuales pueden ser directamente introducidas en los paquetes de transporte.

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

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

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

Figura 15

Además de la tablas de PSI, MPEG-2 define una estructura de secciones privadas (private sections) mediante la cual el estándar es extensible (podríamos definir otras tablas diferentes además de las ya existentes en MPEG-2). Además, estas tablas nos permiten la transmisión de datos privados.

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

A continuación damos una pequeña descripción del objetivo de cada una de las tablas obligatorias en MPEG-2.

PAT (Program Association Table): La PAT nos da información sobre todos los programas presentes en un transport stream. A través de ella, sabemos en que PID viajan las tablas PMT que nos dan información sobre cada uno de los programas.

La PAT siempre viaja en paquetes de transporte con PID = 0. Evidentemente la tabla PAT será única para cada trama de transporte.

PMT (Program Map Table): Existe una PMT por cada programa presente en el transport stream. En ella se da información sobre todos los elementary streams asociados a un programa, de tal forma que el receptor es capaz de localizarlos y decodificarlos. Por lo tanto para cada elementary stream nos indica:

• PID en el que viaja la trama fundamental.

• Tipo de trama fundamental (vídeo, audio, datos…).

• Descriptores asociados a la trama fundamental.

El PID en el que viaja cada una de las PMTs (una para cada programa presente en la trama de transporte) es asignado por la PAT.

CAT (Conditional Access Table): Nos da información sobre el sistema de acceso condicional presente en el transport stream. Sólo es obligatoria en caso de que algún programa del transport stream esté codificado. La tabla PAT siempre viaja en paquetes de transporte de PID = 1.

NIT (Network Information Section): Transporta información de red. Esta red puede estar formada por varios canales físicos diferentes, que a su vez transporten tramas de transporte independientes entre si. El PID en el que viaja la NIT es asignado por la PAT. La NIT es una tabla opcional, pero en caso de estar presente, conforma el programa numero 0 en la PAT.

La sintaxis de las secciones que conforman cada una de las tablas está definida en los anexos de esta introducción.

3.4. PAT-PMT Tuning…

En este punto se pretende aclarar los mecanismos mediante los cuales un receptor MPEG-2 es capaz de localizar un programa dentro de una trama de transporte, así como cada uno de los Elementary Streams que conforman dicho programa.

Las tablas PMT (una para cada programa presente en la trama de transporte) nos indican en que PIDs podemos encontrar cada uno de los elementary streams que conforman un programa, así como el tipo de ES del que se trata.

A su vez, la tabla PAT nos indica los PIDs en los que podemos encontrar las PMTs de cada uno de los programas.

Por lo tanto, a la hora de presentar un programa de televisión el receptor de televisión digital realiza los siguientes pasos:

• Captura la PAT (filtra los paquetes de transporte con PID=0)

• Busca en la PAT el PID en el que viaja la PMT del programa que quiere presentar.

• Captura la tabla PMT que describe la estructura de dicho programa (filtra los paquetes de transporte con dicho PID).

• Lee en la PMT los PIDs en los que viajan las tramas elementales que quiere presentar.

Por supuesto, el proceso es mucho más complejo, pero en cualquier caso, no entraremos en mayores detalles. La siguientes figuras muestra gráficamente el proceso de localización de servicios y de las tramas fundamentales asociadas a los mismos.

Figura 16

Figura 17

Los diferentes tipos de elementary streams definidos en MPEG-2 se muestran en la siguiente tabla:

Figura 18

Los tipos de datos más utilizados a día de hoy en MPEG-2 son el 0x02 (vídeo codificado en MPEG-2), 0x03 (audio codificado en MPEG1), 0x05 (secciones privadas MPEG-2), 0x06 (paquetes PES que contienen datos privados) y 0x0B (transmisión de datos mediante DSM-CC object carousel).

NOTA: El hecho de que los streams de tipo 6 sean de datos privados (private data) no significa que esos datos no puedan ser presentados al usuario de televisión. Simplemente se trata de un mecanismo de transmisión de datos definido por MPEG-2.

Trama de Transporte DVB

Una trama de transporte DVB tiene la misma estuctura básica de una trama de transporte MPEG-2, pero añade algunas restricciones y funcionalidades.

En cualquier caso, todo lo dicho anteriormente en esta presentación es aplicable sin perdida de generalidad al estándar DVB.

Antes de nada, vamos a introducir una serie de conceptos nuevos o a renombrar algunos que ya conocíamos.

Elementary Stream: Un elementary stream (ES) es un stream (en castellano podría traducirse como trama) de video, audio o datos binarios codificados en MPEG2. En una trama DVB cada elementary stream viaja en un PID diferente.

Event: Un evento es lo que en lenguaje coloquial se conoce como un "programa de televisión". En cada evento pueden existir varios elementary streams, que pueden ser o no de tipos diferentes. En cualquier caso el protocolo DVB permite la transmisión de eventos de varios tipos, por lo que además de los "programas de televisión" anteriormente mencionados podemos tener programas de radio, o simplemente tramas de datos.

Service: Un servicio es lo que en leguaje coloquial se conoce como un "canal de televisión". Por lo tanto, un servicio ofrece varios eventos uno detrás de otro (en el tiempo). El número de elementary streams presentes en un servicio puede variar a lo largo del tiempo, ya que algunos eventos pueden tener más elementary streams que otros. Al igual que ocurre con los eventos los servicios no tienen porqué ser exclusivamente canales de televisión, pudiendo ser cadenas de radio, o tramas de datos…

En definitiva un servicio es un conjunto de elementary streams agrupados lógicamente.

La siguiente figura expresa a la perfección la idea anterior:

Figura 19

Es importante destacar que DVB llama servicio (service) a lo que MPEG2 llama programa (program), ya que en algunas fuentes bibliográficas estos dos términos se usan indistintamente.

Multiplex: Un multiplex es un conjunto de servicios multiplexados en MPEG2. Cada multiplex viaja en una frecuencia diferente, siendo su velocidad máxima de transmisión de 40 Mbps (Megabits por segundo).

Llegados a este punto podemos entender la siguiente figura, en la que se nos muestran los diferentes servicios y elementary streams de un multiplex, así como el PID en el que viajan y su velocidad de transmisión:

Figura 20

Como podemos observar el ancho de banda (o la velocidad de transmisión) ocupado por los diferentes elementary streams es muy diferente. De esta forma, un elementary stream de video suele ocupar alrededor de los 3.5 Mbps, un ES de audio unos 0.2 Mbps, un ES de datos unos 1 Mbps… etc.

En la figura también se observa como algunos servicios (en la figura se les llama program siguiendo la terminología MPEG2) contienen varios ES, mientras que otros están compuestos por un solo elementary stream.

Normalmente en cada multiplex suelen viajar alrededor de 6 o 7 canales de televisión más alguno de datos y de radio.

Bouquet: Un bouquet es un grupo de servicios agrupados lógicamente (paquete de fútbol, paquete de cine…). De esta forma podemos tener en cada bouquet más (o menos) servicios de los que caben en un multiplex, y al mismo tiempo seguir teniéndolos ordenados sin bajar la eficiencia.

4.1. TABLAS DVB

DVB dispone de un mecanismo de información basado en tablas. El conjunto de tablas presentes en una trama de transporte constituyen el Service Information de la trama.

Como hemos visto anteriormente, MPEG-2 define una serie de tablas obligatorias, además de la tabla NIT de carácter opcional.

DVB, además de las tablas MPEG-2 añade otro conjunto de tablas obligatorias más otro grupo de tablas opcionales. Nótese que la tabla NIT en el estándar DVB pasa a ser obligatoria y que se fija su PID a 0x10.

La siguiente figura describe lo anterior gráficamente.

Figura 21

En caso de que se quiera construir una trama DVB completa, al menos las tablas señaladas en rojo y las señaladas en azul (primera dos columnas de la tabla, de izquierda a derecha) deberían estar presentes en dicha trama de transporte.

Todas las tablas DVB obligatorias, excepto la tabla PMT, viajan en PIDs fijados por el estándar. El caso de las tablas PMT es diferente, ya que el PID en el que viajan se señala dentro de la tabla PAT. En la figura anterior también se pueden observar dichos PIDs.

Las tablas MPEG-2 ya fueron definidas en el punto anterior, por lo que solamente añadimos las descripciones de las tablas obligatorias DVB que además no estuvieran definidas por MPEG-2.

SDT (Service Description Table): En esta tabla tenemos una lista de los servicios asociados a cada transport stream. En ella se muestran los nombres y los parámetros asociados a cada servicio. Esta información se transmite mediante descriptores, principalmente el "service descriptor". Además, la tabla SDT puede transportar información de temporización de los diferentes servicios.

EIT (Event Information Table): Esta tabla nos da información sobre los eventos presentes o futuros de la trama de transporte. De esa forma el receptor conoce el momento de inicio del evento y su duración, entre otras cosas.

TDT (Time and Date Table): Esta tabla se utiliza para transmitir la hora y fecha actual, de tal forma que el receptor pueda sincronizarse a ella.

Bibliografía y Referencias

[1] ISO/IEC 13818-1 1996 Information technology – Generic coding of moving pictures and associated audio information. Part1: Systems.

[2] ISO/IEC 13818-2 1996 Information technology Generic coding of moving pictures and associated audio information. Part 2: Video (MPEG-2 Video)

[3] ISO/IEC 13818-3 2nd Ed. 1998 Information technology – Generic coding of moving pictures and associated audio information. Part 3: Audio (MPEG-2 Audio).

[4] EN 300 468 1.5.1 Digital video broadcasting. Specification for Service Information (SI) in Digital Video Broadcasting (DVB) systems

[5] "La Television Digital" Herve Benoit. Editorial Paraninfo

[6] "MPEG-2 Systems" Michael Isnardi, Sarnoff Corporation

[7] "Tutorial de Televisió Digital" elaborado por el "Laboratori de Vídeo i Televisió" y el CeTVD (Centre de Televisió Digital) d'Enginyeria La Salle

[8] http://www.dvb.org

[9] http://www.mhp-interactive.org

Enviado por:

Ing.+Lic. Yunior Andrés Castillo S.

"NO A LA CULTURA DEL SECRETO, SI A LA LIBERTAD DE INFORMACION"®

www.monografias.com/usuario/perfiles/ing_lic_yunior_andra_s_castillo_s/monografias

Santiago de los Caballeros,

República Dominicana,

2015.

"DIOS, JUAN PABLO DUARTE Y JUAN BOSCH – POR SIEMPRE"®