ES2422865T3 - Procedimiento de difusión de un flujo de transporte de audio/vídeo numérico en paquetes, especialmente para difusión por línea xDSL - Google Patents

Abstract

Un procedimiento de difusión de un flujo de vídeo digital multiplexado de tipo Flujo de Transporte TS, en elcual: - se escinden en paquetes unos datos de imagen de un flujo elemental ES y se transmiten en forma de unflujo elemental empaquetado TS, estando identificado cada paquete por un identificador de paquete PID propio; - la difusión incluye, en instantes predefinidos, unos puntos de acceso aleatorio correspondientes alcomienzo de difusión de una imagen completa de tipo Intra; y - el procedimiento incluye asimismo la emisión de una pluralidad de tablas, encapsuladas en respectivospaquetes TS (30, 32, 36), permitiendo estas tablas determinar los PIDs de los paquetes (34) que contienen dichos datos de imagen,y siendo necesario el acceso a todas las tablas de esta pluralidad y su tratamiento para permitir, en el lado derecepción del flujo de vídeo digital multiplexado, la recomposición, y eventualmente la desencriptación, de cadaimagen del flujo elemental a partir de los sucesivos paquetes difundidos, procedimiento caracterizado por las etapas previas de: - determinación del tiempo máximo (tmaxPAT, tmaxPMT, tmaxECM) de toma en cuenta y de tratamiento, en el ladode recepción del flujo de vídeo digital multiplexado, de cada una de las tablas de dicha pluralidad de tablas; y - cálculo de una duración (tmaxPAT + tmaxPMT + tmaxECM) de período refractario correspondiente, acumulada parael conjunto de las tablas, y, de manera continua en la difusión: - determinación del instante (tA) del punto de acceso aleatorio próximo; y - emisión del paquete que encapsula la primera de dichas tablas, a más tardar en el instante (tPAT) del puntode acceso aleatorio (tA) próximo, anticipado en la duración (tmaxPAT + tmaxPMT + tmaxECM) de dicho período refractario.

Description

Procedimiento de difusión de un flujo de transporte de audio/vídeo numérico en paquetes, especialmente para difusión por línea xDSL

La invención concierne a la difusión de los flujos de vídeo digitales.

Más en particular, ésta concierne a la difusión de flujos de vídeo mediante canales de transmisión que tan sólo ofrecen una velocidad de transmisión de datos (o "ancho de banda") relativamente pequeña, como en el caso de las transmisiones por IP (Internet Protocol), especialmente de las transmisiones efectuadas sobre un par telefónico trenzado corriente, preexistente, a través de un proveedor de acceso a Internet mediante una tecnología de tipo xDSL (Digital Subscriber Line, línea digital de abonado), principalmente ADSL (Asymmetric DSL).

En concreto, el ancho de banda en xDSL se halla sometido a fuertes restricciones por la técnica de transmisión: depende de la atenuación en el par de cobre telefónico, función a su vez, entre otros factores, de la longitud del par de hilos de cobre (lejanía entre el abonado y el autoconmutador central), del número de puntos de corte y de la calidad del enlace, particularmente del diámetro de los hilos. Para brindar la elegibilidad a un máximo de clientes, se hace necesario por tanto imponer fuertes restricciones sobre el ancho de banda utilizado por los programas de televisión.

El ancho de banda para una difusión por xDSL queda limitado así a unos megabits por segundo (Mbps), como máximo una veintena de megabits por segundo.

Para la difusión de la televisión, en una transmisión de tipo xDSL, el ancho de banda asignado es típicamente una asignación fija de 3,5 Mbps por canal difundido. Por lo tanto, los flujos de audio y de vídeo que se van a difundir son objeto previamente de una compresión mediante un codificador, por medio de procedimientos tales como los que prescriben particularmente las normas ISO/IEC 13818-2 y 3 (MPEG-2).

Tras la compresión, los datos codificados de vídeo, de audio y del sistema conforman respectivos flujos elementales continuos ES (Elementary Stream, flujo elemental), que corresponden cada uno de ellos, por ejemplo, a una imagen del flujo de vídeo o una trama del flujo de audio. Los flujos ES son segmentados a continuación en paquetes de tamaño variable o PES (Packetized Elementary Stream, flujo elemental empaquetado), los cuales a su vez son segmentados a continuación en paquetes de tamaño fijo TS (Transport Stream, flujo de transporte).

Esta segmentación queda definida por la norma internacional ISO/IEC 13818-1 (MPEG-2) eventualmente ampliada o precisada por normas regionales, especialmente la norma europea DVB o la norma americana ATSC. Para información más precisa, se pueden consultar las especificaciones detalladas:

ISO/IEC 13818-1:2007: Information technology - Generic coding of moving pictures and associated audio information: Systems, International Standard ISO/IEC, Vol. 13818-1, y Dec 2000, pp. l-XVII, 1, XP002601409; y

ITU-T Recommendation H.262, International Standard ISO/IEC 13818.2 MPEG-2 Video, Transmission of Non-Telephone Signals. Information Technology - Generic Coding of Moving Pictures and associated Audio Information: Video, ITU-T Telecommunication Standardization Sector of ITU, Geneva, CH, 01 July 1995, pp. 1-211, XP000198491.

Los paquetes TS provenientes de los diferentes flujos elementales son multiplexados a continuación para conformar un tren final de datos binarios, el cual será emitido en soportes de transmisión tales como satélite, cable, difusión hertziana terrestre o red IP, especialmente difusión xDSL a través de una línea telefónica fija preexistente.

Cada paquete TS es un paquete de 188 bytes que comprende una cabecera de al menos 4 bytes, que comprende diferentes indicadores que califican el contenido del paquete, así como un número codificado en 13 bits (de 0000 a 8191) denominado PID (Packet IDentifier, identificador de paquete), caracterizador de la pertenencia de los datos del paquete.

Para restituir correctamente el programa (o "servicio") de televisión solicitado por el usuario, el decodificador debe conocer los PID de los diferentes paquetes del programa.

La norma ISO/IEC 13818-1 define al efecto dos tablas de consulta, encapsuladas a su vez en paquetes elementales TS que permiten transportar el contenido de estas tablas:

-

la PAT (Program Association Table, tabla de asociación de programa), la cual siempre es transportada en paquetes de PID '0000', da la lista de los programas audiovisuales presentes en el flujo de transporte, así como los PIDs de los paquetes que transportan las PMTs asociadas a cada uno de esos programas;

-

la PMT (Program Map Table, tabla de correspondencia de programa) da la lista de los flujos elementales de vídeo, de audio, de subtítulos, etc., asociados a un programa particular, así como su tipo, diferentes propiedades y el PID de los paquetes de contenido de cada uno de esos flujos; esta tabla está encapsulada y puede ser transportada

en paquetes de PID arbitrario, cuyo valor viene dado por la PAT.

El decodificador que recibe el flujo TS procede de la siguiente manera:

-

en primer lugar, envía las órdenes necesarias a la capa física para seleccionar el flujo de transporte (frecuencia del satélite, frecuencia del cable, frecuencia hertziana o dirección multidifusión en las redes de tipo IP);

-

lee todos los paquetes de ese flujo hasta encontrar un paquete de PID '0000' que define una PAT;

-

busca entonces en la PAT el o los programa(s) pertinente(s), localiza el o los PID(s) de la PMT o de las PMTs necesaria(s);

-

a continuación lee todos los paquetes siguientes hasta recuperar la(s) PMT(s) solicitada(s);

-

extrae, de esta(s) PMT(s), la lista de los flujos elementales (de vídeo, de audio, de subtítulos; de encriptación, servicios interactivos) necesarios para los servicios;

-

y a continuación programa el demultiplexador para enviar los PIDs solicitados hacia los módulos de equipo decodificador.

En ocasiones, para el correcto funcionamiento del decodificador son necesarias otras tablas, no definidas en ISO/IEC 13818-1, particularmente tablas encapsuladas en paquetes de tipo ECM (Entitlement Control Message, mensaje de control de permisos) que contienen las claves de desaleatorización de los flujos protegidos. La norma MPEG define en concreto que el PID que transporta los ECMs debe estar indicado en la PMT de cada programa encriptado. Por lo tanto, los módulos de equipo decodificador deberán esperar a que esos paquetes hayan sido recibidos para poder desencriptar el programa correspondiente.

No basta sin embargo con que los módulos de decodificación reciban los PIDs debidos en claro para que se termine la operación.

En efecto, puesto que los datos codificados pasan por varias etapas de encapsulamiento antes de ser segmentados en paquetes TS, es necesario localizar los comienzos de las estructuras PES y luego de las diferentes metaestructuras propias de cada tipo de datos: comienzo de trama de audio, comienzo de imagen, etc., correspondientes a cada uno de los paquetes PES que a su vez habían sido fraccionados en paquetes TS.

Esta operación generalmente se lleva a cabo localizando una secuencia de arranque en varios bytes que caracteriza el comienzo de un elemento sintáctico y permite, por una parte, el acceso al comienzo de una imagen codificada (así, los cuatro bytes '0x0 0x0 0x1 0x0' según ISO/IEC 13818-2, MPEG-2).

En el caso del vídeo, esta etapa aún no es suficiente.

En efecto, los algoritmos de compresión conducen a la producción de varios tipos de imágenes, denominados I, P o

B:

-

una imagen I (Intra) corresponde a una imagen completa comprimida y codificada;

-

una imagen de tipo P (Predictivo) es codificada prediciendo el mayor número posible de zonas de la imagen (macrobloques) mediante referencias a zonas similares de imágenes I o P de referencia asociadas a vectores de movimiento;

-

las imágenes de tipo B (Bidireccional) aumentan aún más la eficiencia de compresión comparando la imagen que ha de codificarse con las imágenes anteriores y siguientes.

Las únicas imágenes que es posible obtener íntegramente de un paquete PES dado son por tanto las imágenes I, que no precisan para ser leídas de ningún contexto.

El instante correspondiente del flujo en el cual se recibirá el primer paquete de una imagen I se denomina "punto de acceso aleatorio".

En conclusión, después de una operación de cambio de canal, el decodificador tan sólo podrá restituir el nuevo programa después de haber efectuado las siguientes operaciones sucesivas:

-

selección física o lógica de la capa física correspondiente a las nuevas características de la portadora que conduce el programa seleccionado;

-

espera de la PAT y selección del programa;

-

espera de la PMT y selección de los flujos elementales asociados;

-

si se trata de un flujo protegido, espera de la ECM y programación de la capa de desencriptación;

-

para cada flujo elemental, espera de las estructuras sintácticas de alto nivel (PES, comienzo de imagen o de trama, etc.);

-

para el vídeo, espera de la imagen I próxima.

Se comprenderá que, con tal algoritmo, el tiempo de resincronización del decodificador después de un cambio de programa puede hacerse muy largo. Para evitar esto, las normas de difusión clásica (ISO, DVB y reglamentaciones nacionales) han impuesto un cierto número de restricciones, especialmente:

-

que todas las tablas (PAT, PMT, ECM) sean repetidas regularmente (típicamente, cada 20 a 200 ms);

-

que se inserte una imagen completamente codificada (imagen I) a intervalos regulares (típicamente cada segundo, e incluso cada dos segundos) –por supuesto, al margen de la inserción de una nueva imagen I con cada cambio de plano–.

Estas medidas facultan un acceso aleatorio al flujo de transporte o "zapping" en un tiempo razonable, pero perjudican la eficiencia de la compresión, ya que obligan a añadir periódicamente información redundante.

Esta aproximación es pertinente en el caso de sistemas de difusión clásicos por satélite, cable o difusión hertziana terrestre, debido al notable ancho de banda global, generalmente del orden de 30 a 40 Mbps, el cual hace insignificante la adición de tablas redundantes.

Además, el hecho de difundir varios programas en una misma frecuencia en general permite hacer que las imágenes I de cada programa no surjan al mismo tiempo. Puesto que, estadísticamente, es muy poco probable que todos los programas de un mismo múltiplex presenten en un instante dado una fuerte complejidad que requiera mucho ancho de banda, el multiplexador puede asignar más ancho de banda a los canales que más lo necesitan en un momento dado, según un algoritmo de prioridad de tipo llamado "multiplexación estadística".

En el caso de una transmisión xDSL, el problema es completamente diferente ya que, en la medida en que el par de hilos de cobre generalmente no es capaz de transmitir más que un sólo programa de televisión independientemente, la velocidad de transmisión asignada a la transmisión de un canal es una velocidad de transmisión constante y relativamente pequeña –típicamente, una asignación de 3,5 Mbps por canal–.

El ahorro de ancho de banda es, pues, un factor particularmente crítico. Por añadidura, debido a la ausencia de multiplexación (puesto que el programa es único), no hay que esperar un efecto de reparto estadístico.

Es el propósito de la invención paliar esos inconvenientes y proponer una solución que permita soslayar el dilema entre la reducción del tiempo de resincronización después de un cambio de programa (rapidez del "zapping") y las restricciones de ancho de banda que a día de hoy condicionan la difusión por canales de escasa velocidad de transmisión tales como los canales de difusión xDSL.

Más exactamente, la invención tiene por objeto un procedimiento que comprende las conocidas etapas, expuestas por ejemplo por la norma ISO/IEC 13818-1, indicadas en el preámbulo de la reivindicación 1. Las etapas propias de la invención están enunciadas en la parte caracterizadora de este reivindicación 1, y las reivindicaciones secundarias están orientadas a diversas características subsidiarias ventajosas.

Se va a describir ahora un ejemplo de puesta en práctica de la invención, con referencia a los dibujos que se acompañan, en los que las mismas referencias numéricas designan a través de las distintas figuras elementos idénticos o funcionalmente semejantes.

La Figura 1 ilustra de manera esquemática las diferentes etapas de creación de los flujos y su multiplexación mediante el dispositivo de codificación.

La Figura 2 muestra más exactamente el modo en que se descompone la estructura de cada uno de los flujos y de los paquetes.

La Figura 3 muestra la relación entre las diversas tablas, encapsuladas en paquetes, destinadas a permitir la decodificación del programa.

La Figura 4 ilustra la manera de calcular, en la manera característica de la invención, el instante óptimo de envío de la tabla PAT después de haber determinado el instante de acontecimiento del punto de acceso aleatorio próximo.

La Figura 5 ilustra una variante de la Figura 4, correspondiente a una situación en la que el tamaño de la tabla PMT no le permite ser encapsulada en un sólo paquete.

En la Figura 1, se ha ilustrado esquemáticamente la manera en que mediante el circuito de codificación son codificados, empaquetados y multiplexados los diversos flujos de vídeo, de audio y de datos.

El flujo de vídeo es objeto de una primera codificación (compresión, definición de imagen I, P o B, etc.). Esta codificación pone en práctica particularmente una memoria intermedia 12 que permite realizar un análisis anterior de las imágenes venideras (típicamente sobre 5 a 40 imágenes) según una técnica de anticipación llamada de "lookahead" consistente en "mirar hacia adelante". Esta memoria intermedia existe en la mayoría de los dispositivos actuales y es utilizada especialmente con dos fines:

-

por el verificador de memoria de vídeo (VBV) del modelo de conformidad T-STD definido por ISO/IEC 13818-1, que impone avanzar (de una manera no desdeñable, en ocasiones del orden de un segundo) le emisión de determinadas imágenes respecto a su fecha ideal de decodificación;

-

por los multiplexadores estadísticos, que procuran repartir los picos de ancho de banda entre cada flujo elemental y por tanto desplazan voluntariamente determinados paquetes en el tiempo, dentro de los límites permitidos por el modelo T-STD.

Esta memoria intermedia se utilizará igualmente para llevar a la práctica la invención, mediante el conocimiento a priori de la imagen próxima de referencia con compresión y codificación completa de la imagen (codificación I), correspondiente al "punto de acceso aleatorio" próximo.

El flujo resultante ES a la salida de la memoria intermedia 12 se segmenta a continuación en paquetes de tamaño variable (bloque 14), correspondiendo típicamente cada paquete a una imagen del flujo de vídeo.

Un tratamiento semejante se aplica al flujo de audio, siendo los bloques 16, 18 y 20 homólogos de los bloques 10, 12 y 14 referentes al flujo de vídeo.

Finalmente, mediante el bloque 22 unos datos son asimismo objeto de una segmentación en paquetes.

Los paquetes así obtenidos a la salida de los bloques 14, 20 y 22 se multiplexan conjuntamente (bloque 24), operación esta que tiene por objeto crear un flujo de transporte constituido a partir de una sucesión de paquetes TS que tienen todos ellos la misma dimensión (188 bytes), lo cual impone por tanto una segmentación suplementaria, de los paquetes PES en subpaquetes TS.

La estructura de los diversos paquetes se ilustra en la Figura 2, donde se ha representado:

-

en la línea (a), la estructura del flujo ES de vídeo (flujo continuo constituido a partir de una sucesión de imágenes codificadas);

-

en la línea (b), la estructura de los paquetes PES de tamaño variable;

-

en la línea (c), los diferentes paquetes TS procedentes de la segmentación de un paquete PES dado; y

-

en la línea (d), más exactamente la estructura de un paquete TS, que comprende una cabecera 26 de cuatro bytes (al menos) y una carga útil 28 constituida por el resto de los 188 bytes.

La cabecera 26 comprende en primer lugar un byte de sincronización '0x47', así como un identificador de paquete PID, que es un número codificado en 13 bits (de 0000 a 8191). La cabecera incluye asimismo diversos indicadores tales como:

-

contador de continuidad CC (de 00 a 15), que permite tener asegurado que la concatenación de los sucesivos paquetes TS de una misma imagen es correcta;

-

indicador RAI (Random Access Indicator, indicador de acceso aleatorio) que señaliza que el paquete TS corresponde al comienzo de una imagen de tipo I (punto de acceso aleatorio);

-

indicador PCR (Program Clock Reference, referencia de reloj de programa), que sirve para el marcado temporal del paquete TS;

-

indicación de que el flujo está encriptado, etc.

La carga útil 28 se constituye, bien sea a partir de datos de contenido propiamente dicho (flujo de vídeo, de audio, etc.), o bien de tablas, encapsuladas en forma de un paquete TS, las cuales necesitará el decodificador para recomponer los diferentes flujos de vídeo/audio/datos a partir de la secuencia de los paquetes TS transmitidos en el flujo.

La Figura 3 ilustra la jerarquía de estas diferentes tablas, encapsuladas todas ellas en paquetes de tipo TS 30, 32, 34 ó 36.

La tabla PAT siempre es transportada dentro de un paquete 30 cuyo valor de PID es '0000'. Esta da la lista de los programas presentes en el flujo de transporte (en el caso de una transmisión por xDSL, en realidad no habrá más que un sólo programa), así como el o los PID(s) del o los paquete(s) 32 que transporta(n) las PMTs asociadas a cada programa.

La PMT, generalmente encapsulada en un sólo paquete 32, da la lista de los flujos elementales asociados a un programa concreto, así como su tipo, diferentes propiedades, y los PIDs de los paquetes 34 de contenido que transporta cada flujo ES. El PID del paquete 32 que encapsula la PMT puede ser arbitrario y su valor es conocido a tenor del contenido de la PAT encapsulada en el paquete 30.

Si la emisión de una tabla PAT o PMT requiere más de 184 bytes, luego más de un paquete TS, se segmenta la tabla en varios paquetes TS, lo cual, sin embargo, es rarísimo para los flujos de transporte que no incluyen más que un sólo programa.

En el caso de un flujo encriptado, la PMT encapsulada en el paquete 32 apunta igualmente hacia paquetes TS 36 de tipo ECM, que contienen las claves de desencriptación de los flujos protegidos.

En una configuración convencional, las tablas PAT, PMT y eventualmente ECM son reemitidas a intervalos regulares, independientemente de la transmisión de los flujos de contenido, por ejemplo cada 20 a 100 ms. Está previsto asimismo reemitir una imagen I a intervalos regulares, por ejemplo cada segundo, e incluso cada 2 segundos (y, naturalmente, al menos con cada cambio de plano).

Según se ha indicado anteriormente, estas medidas perjudican la eficiencia de la compresión, pues obligan a añadir información redundante de manera periódica.

El punto de partida de la invención radica en la comprobación de que, cuando el flujo de transporte no tiene más que un sólo programa que transmitir y, por tanto, no comprende más que un sólo flujo elemental de vídeo, es sencillo calcular la posición del punto de acceso aleatorio próximo que será utilizable por el decodificador. Este punto de acceso aleatorio es conocido de antemano por la técnica de anticipación look ahead antes descrita, en virtud de las imágenes contenidas en la memoria intermedia 12.

La idea en que se fundamenta la invención consiste, una vez conocida la posición temporal de ese punto de acceso aleatorio, en fijar en el tiempo la emisión de la PAT y de las tablas que la siguen (PMT y, eventualmente, ECM) en esa posición temporal.

Esta manera de proceder la permite especialmente el hecho de que los tiempos máximos de toma en cuenta de las tablas por parte de los decodificadores utilizados pueden ser conocidos a priori, por el administrador del servicio.

Ello presupone que la red xDSL es una red cerrada de operador y que los tipos de terminales puestos a disposición del público son conocidos.

Esas duraciones se designarán en lo sucesivo tmaxPAT, tmaxpMT y tmaxECM. Su valor típico es, para cada una de ellas, del orden de 150 ms, valor que a efectos prácticos corresponde, mayoritariamente, al tiempo de toma en cuenta de la interrupción generada mediante los circuitos de soporte físico (hardware) por el procesador encargado del tratamiento lógico de los datos.

Así, si un decodificador necesita por ejemplo 150 ms para analizar y tomar en cuenta una PAT, de nada sirve enviar una PMT durante ese espacio de tiempo, pues la PMT enviada se perderá y será necesario esperar a la siguiente.

La manera de proceder para obtener el sincronismo según la invención se ilustra en la Figura 4.

A partir del contenido de la memoria intermedia de vídeo 12, el multiplexador calcula la fecha del punto de acceso aleatorio tA próximo, es decir, la fecha de envío del primer paquete TS de la imagen I próxima (enviándose esta imagen, según se ha indicado antes, en cualquier caso al menos cada segundo).

El multiplexador calcula a continuación, hacia atrás, las fechas mínimas tECM, tPMT y tPAT de envío de las diferentes tablas respectivas para que cada una de ellas pueda ser tomada en cuenta por el procesador encargado de la decodificación:

tECM = tA – tmaxECM,

tPMT = tECM � tmaxPMT y

tPAT = tPMT – tmaxPAT.

Conociendo el instante tA (atendiendo al marcado temporal del paquete TS correspondiente), se puede definir así una fecha tPAT en la que, a más tardar, deberá ser enviada la PAT si queremos que se puedan tomar en cuenta las tablas PMT y ECM que vendrán tras ella.

Posteriormente a esta fecha, no será posible la toma en cuenta, y se llamará "período refractario" a este período en cuyo transcurso es inútil enviar tablas.

A partir del instante tA y hasta el instante tPAT a más tardar, se dispone así de una "ventana de zapping" en cuyo transcurso se tiene la certeza de que todas las tablas podrán ser tomadas en cuenta sucesivamente.

El instante de envío de la tabla PAT se elige lo más cerca posible de (pero con anterioridad a) el instante tPAT, evitando hacer que el envío preceda demasiado al instante tPAT, pues, de lo contrario, se disminuirá el tamaño de la ventana de zapping eficaz, con una degradación, al final, del tiempo medio de zapping. Dicho de otro modo, el instante tPAT es el último momento posible para empezar a enviar las tablas (cualquier tabla enviada con posterioridad no tendrá tiempo de ser tomada en cuenta en algunos decodificadores antes de la próxima tabla, o antes del punto de acceso aleatorio tA).

Se hace notar que la frecuencia de envío de las PATs es la misma que la de los puntos de acceso aleatorio: si se envía una imagen I cada segundo, se enviará una sola PAT por segundo.

Esta técnica permite en primer lugar optimizar el tiempo medio de zapping.

Por otra parte, permite reducir de manera sustancial las necesidades de ancho de banda: en efecto, cualquier tabla que se insertara fuera de los períodos indicados carecería de efecto, debido a la ausencia de punto de acceso aleatorio en el flujo de vídeo, pero sería redundante y por tanto acabaría incidiendo negativamente en la velocidad de transmisión de información. Por lo tanto, se puede ahorrar la codificación de esas tablas, con una consiguiente ganancia en cuanto a ancho de banda.

En concreto, las tablas PAT y PMT no pueden no ser enviadas más que cada 300 a 500 ms, en lugar de serlo cada 20 a 200 ms como en las técnicas que habitualmente se ponen en práctica.

Se pueden introducir diversos perfeccionamientos en la invención, especialmente introduciendo:

-

un intervalo mínimo tmin entre la emisión de dos tablas de igual tipo: en efecto, en ciertos casos (serie de destellos, por ejemplo), el codificador puede verse llevado a introducir muchas imágenes I en un período dado, lo cual aumentaría el ancho de banda asignado a la emisión de las tablas PAT, PMT, ... El intervalo mínimo tmin, por ejemplo de 200 ms, permitirá acotar la velocidad de transmisión utilizada para cada tabla, sin perjudicar por ello el acceso aleatorio, pues las tablas siguen siendo repetidas regularmente;

-

un intervalo máximo tmax entre la emisión de dos tablas de igual tipo: si bien es cierto que esto tendrá por efecto el introducir suplementarias tablas redundantes, que carecerán de efecto sobre el tiempo de acceso, y el aumentar por tanto la velocidad de transmisión asignada a la emisión de las tablas, algunos estándares, especialmente DVB, imponen un intervalo máximo (500 ms según DVB) para la repetición de las tablas, intervalo que conviene respetar para obtener la conformidad con la norma.

También puede ocurrir que la emisión de una tabla requiera más de 184 bytes, por tanto, más de un paquete TS; en tal caso, la tabla se segmenta en varios paquetes TS, que pueden ser separados en el tiempo varios milisegundos para cumplir especialmente con las restricciones del modelo T-STD. Si esto debe suceder, hay que diferenciar en el cálculo del período refractario antes explicado (i) el tiempo óptimo de envío del último paquete de la tabla (en el lado izquierdo de las tres ecuaciones antes dadas), y (ii) el tiempo óptimo de envío del primer paquete de la tabla (lado derecho de las ecuaciones antes dadas). Esto equivale a introducir, según se ilustra en la Figura 5, una constante suplementaria LtPMT (por ejemplo), típicamente del orden de 20 ms, que corresponde al tiempo de toma en cuenta de un segundo paquete que contiene el final de la tabla PMT.

Claims (10)

1. REIVINDICACIONES

   1. Un procedimiento de difusión de un flujo de vídeo digital multiplexado de tipo Flujo de Transporte TS, en el cual:

   -

   se escinden en paquetes unos datos de imagen de un flujo elemental ES y se transmiten en forma de un flujo elemental empaquetado TS, estando identificado cada paquete por un identificador de paquete PID propio;

   -

   la difusión incluye, en instantes predefinidos, unos puntos de acceso aleatorio correspondientes al comienzo de difusión de una imagen completa de tipo Intra; y

   -

   el procedimiento incluye asimismo la emisión de una pluralidad de tablas, encapsuladas en respectivos paquetes TS (30, 32, 36),

   permitiendo estas tablas determinar los PIDs de los paquetes (34) que contienen dichos datos de imagen,

   y siendo necesario el acceso a todas las tablas de esta pluralidad y su tratamiento para permitir, en el lado de recepción del flujo de vídeo digital multiplexado, la recomposición, y eventualmente la desencriptación, de cada imagen del flujo elemental a partir de los sucesivos paquetes difundidos,

   procedimiento caracterizado por las etapas previas de:

   -

   determinación del tiempo máximo (tmaxPAT, tmaxPMT, tmaxECM) de toma en cuenta y de tratamiento, en el lado de recepción del flujo de vídeo digital multiplexado, de cada una de las tablas de dicha pluralidad de tablas; y

   -

   cálculo de una duración (tmaxPAT + tmaxPMT + tmaxECM) de período refractario correspondiente, acumulada para el conjunto de las tablas,

   y, de manera continua en la difusión:

   -

   determinación del instante (tA) del punto de acceso aleatorio próximo; y

   -

   emisión del paquete que encapsula la primera de dichas tablas, a más tardar en el instante (tPAT) del punto de acceso aleatorio (tA) próximo, anticipado en la duración (tmaxPAT + tmaxPMT + tmaxECM) de dicho período refractario.

2. 2.

   El procedimiento de la reivindicación 1, en el que dicha pluralidad de tablas comprende una tabla PAT de asociación de programa, seguida de una tabla PMT de correspondencia de programa.

3. 3.

   El procedimiento de la reivindicación 1, en el que dicha pluralidad de tablas comprende además una tabla ECM de mensaje de control de permisos, para la desencriptación de las imágenes del flujo elemental.

4. 4.

   El procedimiento de la reivindicación 1, en el que se prevé además un intervalo mínimo entre dos emisiones sucesivas de tablas de igual tipo de dicha pluralidad de tablas.

5. 5.

   El procedimiento de la reivindicación 1, en el que se prevé además un intervalo máximo entre dos emisiones sucesivas de tablas de igual tipo de dicha pluralidad de tablas.

6. 6.

   El procedimiento de la reivindicación 1, en el que una tabla de un tipo dado se encapsula en un sólo paquete y dicho tiempo máximo de toma en cuenta y de tratamiento de esa tabla corresponde al tiempo de toma en cuenta y de tratamiento de un paquete.

7. 7.

   El procedimiento de la reivindicación 1, en el que una tabla de un tipo dado se encapsula en varios paquetes y dicho tiempo máximo de toma en cuenta y de tratamiento de esa tabla corresponde al tiempo de toma en cuenta y de tratamiento de un paquete, aumentado en el tiempo de toma en cuenta de uno(s) paquete(s) suplementario(s).

8. 8.

   El procedimiento de la reivindicación 1, en el que una tabla de un tipo dado se emite tan sólo una vez entre dos puntos de acceso aleatorio sucesivos.

9. 9.

   El procedimiento de la reivindicación 1, en el que dicha difusión del flujo de vídeo digital multiplexado es una difusión mediante red como programa único.

10. 10.

    El procedimiento de la reivindicación 9, en el que dicha difusión mediante red es una difusión por línea xDSL.