ES2341357T3

ES2341357T3 - Procedimiento y sistemas para la prevencion de la emulacion de codigo inicial y de relleno de datos.

Info

Publication number: ES2341357T3
Application number: ES06021437T
Authority: ES
Inventors: Gary J. Sullivan; Stephen J. Estrop
Original assignee: Microsoft Corp
Current assignee: Microsoft Corp
Priority date: 2002-01-22
Filing date: 2003-01-22
Publication date: 2010-06-18
Anticipated expiration: 2023-01-22
Also published as: PT1753244E; JP5394528B2; EP1468567A2; US7505485B2; HK1069700A1; JP2005516496A; WO2003063500A1; WO2003063499A2; US7839895B2; DE60310368T2; JP2006502605A; JP4503294B2; DE60311231D1; EP1468566A1; JP2011205665A; ATE352171T1; CN1618236A; DE60311231T2; EP1753244B1; EP1753244A1

Abstract

En un descodificador, un procedimiento que comprende: el relleno de una carga útil de datos en un flujo de datos con uno o más bits de relleno; estando el procedimiento caracterizado por: la inserción de uno o más bits de relleno después de la carga útil de datos en los datos rellenados, en el que la inserción de los uno o más bits de relleno incluye: la inserción (202) de un bit de 1 después de la carga útil de datos; la inserción (206) de cualquier bit de 0 después del bit de 1, en el que el número de bits insertados varía dependiendo del número de bits existentes en la carga útil de datos, de manera que los datos rellenados consisten en un número entero de bytes (204) que finaliza con un byte de no cero que incluye los uno o más bits de relleno y de tal manera que el byte de no cero que incluye los uno o más bits de relleno difiere de un primer byte de un código inicial y, de esta forma, facilita la prevención de la emulación del código inicial; comprendiendo el procedimiento la inserción (208) uno o más bytes iguales a 0 x 00 después del byte de no cero que finaliza los datos rellenados y antes del código inicial.

Description

Procedimiento y sistemas para la prevención de la emulación de código inicial y de relleno de datos.

La presente invención está relacionada con los procedimientos y sistemas para la prevención de la emulación de código inicial y de relleno de datos.

Los datos digitales son típicamente transmitidos desde algún tipo de transmisor hasta algún tipo de receptor. Los transmisores típicamente incluyen un codificador que codifica los datos de transmisión; y los receptores típicamente incluyen un descodificador que descodifica los datos que recibe. Hay diferentes tipos de datos digitales, como por ejemplo datos de vídeo, datos de audio, datos de audio/vídeo, datos de texto, datos de programas ejecutables por computadora, datos de archivos, información de bases de datos, y similares. Cuando los datos digitales son transmitidos, son típicamente transmitidos en algún tipo de canal. De manera equivalente, una memoria de computadora o cualquier dispositivo de almacenamiento o medio de almacenamiento puede ser considerado como canal de transmisión a los fines de la presente memoria.

Cuando los datos digitales son transmitidos, es importante poder encontrar unos puntos específicos dentro de los datos del canal. Esto se lleva a cabo con distintas finalidades, como por ejemplo para localizar puntos que posibiliten la recuperación de errores o pérdidas en la transmisión de los datos a través del canal, puntos que posibiliten el inicio del proceso de descodificación en una localización distinta del inicio del entero flujo, o puntos que posibiliten la búsqueda de diferentes puntos de datos que sean utilizados con diferentes propósitos. De esta forma, por ejemplo, en el lado del descodificador, los descodificadores y otros componentes que procesan datos digitales a menudo necesitan saber el contexto de los datos para que los datos puedan ser adecuadamente procesados. Esto no sería tan importante si uno fuera capaz de comenzar con el primer bit que fue enviado y el descodificador fuera capaz de ejecutar sin ningún error. En este situación, en teoría, el descodificador podría simplemente efectuar el seguimiento de la información que estaba siendo enviada de acuerdo con el conocimiento de cuál es el formato de los datos. Por desgracia, esta situación ideal a menudo no se produce. Por el contrario, se producen errores y otras contingencias que representan otros tantos desafíos a los que diseñan y utilizan los sistemas que transmiten y reciben datos digitales. En algunos casos, como por ejemplo al sintonizar un flujo de difusión de datos en curso, el descodificador no puede comenzar por el principio de la transmisión de datos. La localización de los puntos mediante el análisis sintáctico del formato de datos puede, así mismo, requerir una cantidad considerable de un complejo procesamiento en un des-
codificador.

En muchos tipos de entornos de canales, a dichas cuestiones se les da respuesta mediante la provisión, dentro de los datos, de unos llamados marcadores de resincronización. Los marcadores de resincronización proporcionan un mecanismo mediante el cual un sistema puede comenzar su proceso de descodificación o recuperar un error. Por ejemplo, cuando los datos digitales son transmitidos en flujo continuo con una serie de bits o de bytes, la incorporación de los marcadores de resincronización en el flujo puede proporcionar un descodificador con un punto de referencia a partir del cual recuperarse en el caso de que se produzca un error en la transmisión.

Una manera de que los marcadores de resincronización puedan ser empleados se produce en el contexto de los códigos iniciales. Un código inicial es una cadena de bits o de bytes con un valor específico. En general, muchos sistemas tienden a acarrear bytes (por ejemplo, los Sistemas H.222.0/MPEG-2), de manera que los códigos iniciales pueden ser definidos como una cadena de bytes valorados de forma unívoca. La cadena unívoca de bytes proporciona un patrón cuya presencia indica un punto de resincronización. Un punto de resincronización típicamente indica el inicio o la frontera de una cierta cantidad de datos descodificables de manera independiente. Por ejemplo, en los datos de Vídeo del H.262/MPEG-2, los puntos de resincronización pueden indicar el inicio de una sección (esto es, una región descodificable de una imagen de manera independiente), el inicio de una imagen, el inicio de un GOP (esto es, "un Grupo de Imágenes" o una secuencia de imágenes descodificables de manera independiente), o el inicio de una nueva secuencia de vídeo. Los flujos de vídeo digitales pueden, así mismo, incluir los llamados datos auxiliares o complementarios los cuales pueden ir precedidos por un código inicial.

Algunas veces los códigos iniciales son utilizados no solo dentro de un flujo de datos, como por ejemplo un flujo de vídeo, sino que son utilizados por un nivel multiplex del sistema. Las características técnicas del Sistema H.222.0./MPEG-2 constituyen un ejemplo de un sistema que utiliza códigos iniciales y acarrea flujos de datos de vídeo intercalados con la información de nivel del sistema y de la información de audio.

Dado que los códigos iniciales pueden ser importantes en el sentido de que proporcionan unos puntos de resincronización dentro de un flujo de datos, es una buena idea evitar la emulación de los códigos iniciales en el flujo de datos en lugares que no están, de hecho, destinados a representar códigos iniciales.

Por ejemplo, considérese lo siguiente. Los códigos iniciales definen un patrón específico de bits o bytes que puede identificar el inicio de una nueva unidad de datos. Se están enviando datos arbitrarios entre los códigos iniciales, entonces es posible que los datos arbitrarios puedan, en y por sí mismos, contener el mismo patrón que el que se utiliza como código inicial. Por ejemplo, si se supone que los datos que están siendo acarreados son completamente aleatorios, entonces, si un código inicial tiene una longitud de K bits, la probabilidad de emular de manera accidental el código inicial al inicio de los bits en algún concreto emplazamiento de bits es de 1/2^{k}.

En algunos casos, puede considerarse que si el número de bits en el código inicial es grande, entonces puede ser bastante improbable que el código inicial sea emulado de forma accidental. Este es el caso que se produce con respecto a algunos formatos de datos de audio. Típicamente, estos formatos no utilizan una tasa de transmisión de bits muy alta medida en bits por segundo, de manera que no es probable que el código inicial sea accidentalmente emulado durante cualquier intervalo de tiempo específico. Con respecto a los datos de vídeo, este no es generalmente el caso, dado que el vídeo a menudo requiere una tasa de transmisión de bits mucho más alta.

En los estándares de codificación de vídeo importantes anteriores (quizás con una excepción), el formato de sintaxis de vídeo dentro de la carga útil de datos ha sido diseñado para evitar la emulación de código inicial. Esto es, si se sabe qué tipo de elementos de datos constituirán la sintaxis de vídeo, entonces se puede diseñar cuidadosamente la sintaxis, de manera que no puedan producirse códigos iniciales accidentales. Por ejemplo, un código inicial en los estándares de codificación de vídeo tradicionales comienza con una cadena larga de bits de 0, seguida por un bit de 1. Esta cadena larga puede contener 23 bits de 0 seguida por un bit de 1. Supóngase que la mayoría de los datos que son enviados son codificados por entropía utilizando códigos de longitud variable (a menudo designados de manera informal como códigos Huffman). Los códigos de longitud variable (VLCs) se definen con fines ejemplares en la presente memoria como códigos con estructura de árbol de profundidad variable que son utilizados parra su selección entre un conjunto de símbolos representados. Una técnica que utiliza VLCs de estructura de árbol binaria, tiene como fin asegurar que la trayectoria del árbol desde la raíz hasta cada hoja representa un símbolo válido siempre que incorpore un "1" en ella en alguna parte, y que la estructura de árbol no es demasiado profunda.

De esta manera, por ejemplo, si uno sabe que cada cadena de código de longitud variable no es más larga de 10 bits y que cada cadena referida tendrá al menos en ella un bit con un valor de 1, entonces se sabe que no hay manera de que una secuencia de datos codificados procedentes del VLC pueda nunca contener más de 18 bits consecutivos de valor cero. Esto es, el peor de los supuestos sería 1000000000 seguido por 0000000001. De esta forma, si se diseña la sintaxis de forma cuidadosa y se inspecciona la localización de cada bit de 0 y de cada bit valorado en 1 para determinar cuántos 0s pueden producirse en una fila, se puede utilizar un código inicial que contenga una cadena más larga de 0s de la que pueda producirse nunca en la sintaxis. Por ejemplo, la sintaxis puede ser diseñada para que una sintaxis válida nunca pueda contener 23 0s en un emplazamiento que no sea un código de inicio. De esta manera, cada aparición de 23 0s debe ser un código inicial y el descodificador puede ser capaz de detectar con precisión los códigos iniciales.

Aunque la operación descrita con anterioridad parece sencilla, la operación puede resultar un cometido bastante difícil porque hay que inspeccionar todos los posibles datos (al nivel de bits) que hay que enviar, en cualquier orden posible en el cual vayan a ser enviados para asegurar que un patrón de código inicial no pueda ser accidentalmente enviado. Esto constituye un arduo procedimiento de diseño de sintaxis tendente a producir errores.

Este proceso de diseño de inspección a nivel de bit describe, en términos generales, la forma en que muchas instrucciones de codificación de vídeo han sido diseñadas en el pasado (esto es, los sistemas H.261/MPGE-1, H.262/MPGE-2, la mayoría de los H.263 y el MPGE-4). Una excepción a ello es el Anexo E del H.263 de la Recomendación ITU-T, el cual utiliza una técnica llamada de codificación aritmética para generar unos bits comprimidos de manera algorítmica a partir de unas condiciones matemáticas. En este sistema, hay un proceso suplementario al final del codificador de entropía el cual inspecciona los bits que son generados y, en el lado del codificador, si hay demasiados 0s en una fila, un bit "marcador" (un bit de 1) es insertado antes de que se encuentre un número predeterminado de 0s. En el lado del descodificador, el descodificador cuenta los ceros y si encuentra el número crítico de ceros, sabe que ha encontrado un código inicial real. Si el descodificador solo ve un cero menos que el número crítico, sabe que el bit de 1 siguiente es un bit marcador insertado para evitar la emulación de código inicial, descarta ese bit, y toma los siguientes bits como continuación de los datos reales.

El problema de esta solución es que hace que el codificador y el descodificador inspeccionen y procesen los datos entrantes al nivel de bit. El análisis y el desplazamiento de la localización de los datos que están siendo procesados por las posiciones de un solo bit resulta difícil y puede sobrecargar de manera indeseable el descodificador. El desplazamiento de bit a bit es, así mismo, una operación exigente para el procesador.

El documento EP1111932 describe la inserción de elementos de sintaxis de bits de marcador en un flujo de bits.

El documento EP1018840 describe la inserción de bits de relleno al final de un paquete de vídeo para conseguir una alineación de bytes de acuerdo con el estándar MPEG-4. Los bits de relleno consisten en una especie de código 0111, donde el primer bit es un cero y los otros bits son 1.

El documento EP1 018 840 A describe un aparato y un procedimiento de generación de flujos codificados, un sistema y un procedimiento de transmisión de datos y un sistema y un procedimiento de edición. Un flujo de datos codificados es generado y representa una pluralidad de imágenes o tramas y presenta una pluralidad de capas que incluye una capa de imágenes en la cual la información del código de tiempo fijada a los datos originales se describe o inserta dentro de aquélla para cada imagen. Dicha información de código de tiempo puede ser insertada en un área de datos de usuario de la capa de imágenes existente en el flujo de datos codificados. En un VITC o un LTC de 72 bits, los 6 bits desde el tercero al octavo bit indican la porción de tramas del código de tiempo, el noveno bit indica la corrección de fase, y los 7 bits del décimo al décimo sexto bit indican la porción de segundos del código de tiempo. El carácter "1" de los bits decimoséptimo, trigésimocuarto, quincuagésimo primero y sexagésimo octavo es un bit marcador para prevenir la aparición sucesiva de 23 ceros. De esta forma, mediante la inserción de un bit marcador a intervalos predeterminados, puede prevenirse la emulación de código inicial. Los 16 bits desde el trigésimoquinto al quincuagésimo y los 16 bits desde el quincuagésimo segundo al sexagésimo séptimo se reservan para permitir que el usuario describa unos datos de usuario deseados. Los últimos cuatro bits son bit de relleno para alinear los
bytes.

Constituye el objetivo de la presente invención proporcionar un procedimiento y un sistema mejorados para prevenir la emulación de código inicial.

Este objetivo se consigue mediante el objeto de las reivindicaciones independientes.

Las formas de realización dependientes se definen en las reivindicaciones dependientes.

Se describen procedimientos y sistemas que proporcionan propuestas de prevención de la emulación de código inicial mediante operaciones llevadas a cabo con una granuralidad más alta que el nivel de bit. Operando en un nivel distinto del nivel de bit, puede potenciarse la eficacia del procesamiento. De acuerdo con una o más formas de realización, un procedimiento de prevención de la emulación de código inicial busca patrones de datos relacionados con porciones de datos de tamaño fijo mayores que los bits simples. Cuando se encuentra un patrón determinado, los datos de emulación de código inicial, son insertados para impedir la emulación de código inicial. Los datos insertados son mayores que un simple bit y, en algunas formas de realización, comprenden un byte. Cuando un descodificador descodifica datos que tenían insertados datos de prevención de la emulación de código inicial, puede fácilmente identificar los códigos iniciales legítimos y a continuación puede eliminar los datos de prevención de la emulación de código inicial para proporcionar los datos originales que se destinaron a ser
acarreadas.

Así mismo, se describe un procedimiento de relleno de datos, el cual posibilita que los datos de carga útil sean redondeados de tamaño hasta un número entero de tamaños de byte, y a continuación posibilita que los datos de relleno sean adicionados de un modo que sea fácilmente detectable por un descodificador.

\vskip1.000000\baselineskip

Breve descripción de los dibujos

La Fig. 1 es un diagrama que flujo que describe las etapas de un procedimiento de acuerdo con una forma de realización.

La Fig. 2 es un diagrama de flujo que describe las etapas de un procedimiento de acuerdo con una forma de realización.

La Fig. 3 es un diagrama de nivel alto de un entorno informático en conexión con el cual pueden ser implementadas una o más formas de realización.

\vskip1.000000\baselineskip

Descripción detallada de la forma de realización preferente Panorámica General

Los procedimientos y sistemas descritos a continuación proporcionan unas propuestas para la prevención de la emulación de código inicial a una granularidad más alta que el nivel de bit. Operando a un nivel más alto que el nivel de bit, puede potenciarse la eficacia del procesamiento. En el contexto de este documento, la operación a un nivel más alto que el nivel de bit pretende referirse a un proceso que busca unos patrones de datos relativos a unas porciones de datos de tamaño fijo mayores que los bits simples. Por ejemplo, las porciones de datos de tamaño fijo pueden incluir bytes (eso es 8 bits), "palabras" (esto es 16 bits), "dobles palabras" (32 bits) y similares. De esta manera, las técnicas inventivas pueden buscar patrones dentro y entre bytes, palabras y similares.

Así mismo, se describe un procedimiento de relleno de datos que posibilita que los datos de carga útil sean redondeados de tamaño hasta un número entero de tamaños de unidades de datos, como por ejemplo cantidades de byte, y posibilita que los datos de relleno sean añadidos de una manera que sea fácilmente detectable por un des-
codificador.

Así mismo, aunque los ejemplos ofrecidos a continuación se analizan en el contexto de datos de vídeo, debe apreciarse y entenderse que las técnicas inventivas pueden ser empleadas en conexión con cualquier tipo de datos que sean típicamente codificados y descodificados y con los cuales sea deseable o necesaria la prevención de relación de codificación de código inicial. Ejemplos de audio incluyen datos de audio, datos de audio/de vídeo, y similares.

La Fig. 1 es un diagrama de flujo que describe las etapas de un procedimiento de acuerdo con una forma de realización. El procedimiento puede ser implementado en cualquier hardware, software, firmware apropiado o combinaciones de éstos. En la forma de realización ilustrada y descrita, el procedimiento es implementado, al menos en parte, en software. Así mismo, el lector puede advertir que el procedimiento se ilustra ofreciendo dos ramas diferentes -
una designada "Codificador" y otra designada "Descodificador". La rama "Codificador" ilustra las etapas que son llevadas a cabo mediante o en conexión con un codificador. De modo similar, la rama "descodificador" ilustra las etapas que son llevadas a cabo mediante o en conexión con un descodificador.

La etapa 100 obtiene o genera una cantidad de datos destinados a su transmisión según un código inicial. Los datos comprenden cualquier dato apropiado. Ejemplos de tipos de datos incluyen, sin limitación, cantidades de datos de vídeo, de datos de audio, de datos de audio/vídeo, y similares. La etapa 101 fija de antemano los datos con código inicial. Esta etapa añade de modo efectivo los códigos iniciales a los datos obtenidos o generados en la etapa 100. La etapa 102 verifica y busca datos entrantes para uno o más patrones de porciones de datos de tamaño fijo. En la forma de realización ilustrada y descrita en el (los) patrón (patrones) que se busca(n) comprende(n) al menos dos porciones de datos de tamaño fijo y cada porción de datos individual comprende al menos dos bits. La etapa 104 determina si se ha encontrado un patrón. Si el patrón no se ha encontrado, el procedimiento se ramifica hasta la etapa 108 en la que los datos pueden ser transmitidos.

Si, por otro lado, el patrón se encuentra, la etapa 106 inserta los datos de prevención de la emulación de código inicial con respecto a los datos que contiene el patrón. En la forma de realización ilustrada y descrita, los supuestos concretos de datos de prevención de la emulación de código inicial comprenden más de 1 bit. De modo preferente, los datos de emulación de código inicial comprenden una cantidad de datos igual en número de bits a una porción de datos individuales de tamaño fijo. De esta manera, cuando la porción de datos de tamaño fijo comprende 8 bits (una cantidad de datos designada como 1 byte), los datos de prevención de la emulación de código inicial comprenden 8 bits. Después de que los datos de prevención de la emulación de código inicial son insertados, la etapa 108 transmite los datos. La etapa 110 determina si hay datos adicionales que deben ser transmitidos antes del siguiente código inicial. Si los hay, entonces el procedimiento retorna a la etapa 102 y avanza de acuerdo con lo descrito con anterioridad. En caso contrario, el procedimiento puede determinar en la etapa 111, si hay datos adicionales que haya que transmitir. Si los hay, el procedimiento se ramifica retornando a la etapa 100. En caso contrario, entonces el procedimiento puede terminar en la etapa 112.

A modo de disgresión, considérese lo siguiente. Adviértase que un ejemplo de empleo de esta técnica particular consiste en separar el código inicial en un "prefijo de código inicial" y un sufijo de "tipo de código inicial", donde el prefijo es una cadena única simple de valores y el sufijo indica el tipo de datos que sigue al código inicial. En particular, esta es la estructura de los códigos iniciales MPEG-2 y H.264/AVC y es la estructura utilizada en la sección con el título "Primer Procedimiento Ejemplar" posterior. Una forma incluso más general de uso que incluye la estructura de prefijo/sufijo como un caso especial, es la idea general de incorporar uno o más patrones de código inicial. A continuación se pueden, tener uno o más patrones de prevención de la emulación. En tanto en cuanto los diversos patrones de código inicial sean independientes de los distintos patrones de prevención de la emulación y que todos estos patrones sean soslayados en el procesamiento de los datos de carga útil, el planteamiento funcionará de acuerdo con ello. Así mismo, no se debe suponer necesariamente que los patrones de código inicial tengan todos la misma longitud. Esto debe ser importante en casos especiales, porque, por ejemplo, los empleos del H.264/AVC pueden ser interpretados como que utilizan códigos iniciales de longitudes múltiples.

En el lado del descodificador, considérese lo siguiente. Una vez que han sido insertados los datos de prevención de la emulación del código inicial por el codificador, pueden ser identificados o suprimidos o ignorados en algún punto para la interpretación adecuada de los demás datos. Así mismo, considérese que, cuando el descodificador recibe los datos transmitidos, puede buscar los datos de código legítimos. Una vez que encuentre los códigos iniciales legítimos, sabe dónde están situados los límites de los datos definidos por el código inicial. Ahora, el descodificador puede avanzar para buscar y suprimir los datos de prevención de la emulación del código inicial para que pueda seguir procesando los datos reales.

Específicamente, la etapa 114 recibe los datos transmitidos que han sido procesados por un codificador para prevenir la emulación de los códigos iniciales. La etapa 118 procesa los datos para encontrar los códigos iniciales. Una vez que se ha encontrado el código inicial y que es adecuadamente procesado (por ejemplo leído y desechado), la etapa 120 busca los datos para identificar los datos de prevención de la emulación del código inicial. Una vez que se encuentran los datos de prevención de la emulación del código inicial, la etapa 122 suprime los datos de prevención de la emulación del código inicial. Una vez que han sido retirados los datos de prevención del código inicial, los datos pueden ser procesados de una manera típica para el modo de datos que han sido recibidos. Por ejemplo, los datos pueden ser consumidos por un dispositivo de consumidor, como en la etapa 124.

\vskip1.000000\baselineskip

Primer Procedimiento Ejemplar

El procedimiento que va a ser descrito ilustra solo un ejemplo específico del procedimiento mostrado y descrito en la Fig. 1. En el procedimiento que va a ser descrito, un byte de unos datos de prevención de la emulación es insertado siempre que una cadena de bytes de N + 1 de datos de carga útil se corresponda, o bien con el entero prefijo del código inicial, o se corresponda con los primeros N bytes del prefijo de código inicial más el valor del byte de prevención de la emulación. Este procedimiento añade datos de forma menos frecuente que el procedimiento descrito en la sección titulada "Segundo Procedimiento Ejemplar" y, por tanto, reduce las exigencias de capacidad de transmisión para enviar los datos de carga útil.

La estructura de prefijo del código inicial del MPEG-2 comienza en una posición alineada a base de bytes y presenta 23 0s seguidos por un 1. Este prefijo de código inicial se expone directamente a continuación:

: 00000000 00000000 00000001

\vskip1.000000\baselineskip

Esta estructura puede ser generalizada como un patrón que comprenda un cierto número de N bytes que tengan el mismo valor, seguidos por algún otro byte que tenga un valor diferente. En el MPEG-2, se puede decir que N = 2, y que los primeros dos bytes son 0 (designados a continuación como "W"), y que el último byte es 1 (designado a continuación como "X"). De esta manera, el prefijo de código inicial tiene el siguiente patrón:

: WWX

\vskip1.000000\baselineskip

Después de estos tres bytes, en el MPEG-2, otro byte sigue e identifica qué tipo de código inicial es. Este byte siguiente se designa como "Y". Esencialmente por tanto, el código inicial consiste en un prefijo de código inicial WWX, seguido por un byte Y que identifica el tipo de código inicial. El entero código inicial del MPEG-2 puede ser representado como:

: WWXY

\vskip1.000000\baselineskip

El prefijo del código inicial (WWX) tiene un valor fijo, mientras que Y tiene una pluralidad de valores diferentes que indican el tipo de código inicial (por ejemplo, sección, imagen, GOP, secuencias, sistema, y simi-
lares).

De acuerdo con una forma de realización de la invención, los datos son procesados buscando el patrón WWX. Cuando el patrón WWX se encuentra, los datos de prevención de la emulación del código inicial son insertados para prevenir la emulación del código inicial. Aquí, los datos de prevención de la emulación del código inicial comprenden un byte Z que tiene un valor independiente de los valores de byte W y X. De esta manera, supóngase que el codificador está inspeccionando datos y advierte el patrón WWX. En respuesta al hallazgo de este patrón dentro de los datos, el codificador inserta un byte con un valor Z para proporcionar el siguiente patrón:

: WWZX

\vskip1.000000\baselineskip

En este punto, el codificador ha asegurado que los datos de carga útil que deben ser transmitidos y procesados por el descodificador no emulan de manera accidental un código inicial o un prefijo de código inicial. Considérese ahora lo siguiente. Justo en el momento en que los datos de carga útil tuvieron la oportunidad de emular un prefijo del código inicial mediante la inclusión arbitraria del patrón WWX, los datos de carga útil tienen también la oportunidad de emular de manera arbitraria los datos que contienen los datos de prevención de la emulación del código inicial. Esto es, los datos de carga útil podrían contener inherentemente el patrón WWZX. Si este es el paso, y el codificador no fuera a hacer nada, cuando el descodificador intentara suprimir los datos de prevención de la emulación del código inicial, suprimirá el byte Z el cual en este caso es el dato real.

De acuerdo con ello, en las formas de realización descritas, el codificador está configurado para prevenir no solo que los datos de carga útil emulen los códigos iniciales o los prefijos de los códigos iniciales, sino que el codificador está configurado para prevenir que los datos emulen los patrones de los datos que resulten del empleo de los datos de emulación de los códigos iniciales. Específicamente, en este ejemplo, si el codificador identifica el patrón WWZ, inserta un byte que tiene un valor Z entre el segundo W y el Z para proporcionar el siguiente patrón (el byte insertado Z es el primer valor Z que aparece a continuación):

: WWZZ

\vskip1.000000\baselineskip

Considérense ahora los datos procesados desde la perspectiva del descodificador. Si el descodificador ve cualquier patrón de bytes que comprenda WWZ seguido por o bien un valor Z o bien un X, sabe que el primer valor Z es un byte de prevención de la emulación que fue insertado por el codificador. De acuerdo con ello, el descodificador puede descartar el primer valor Z. De esta forma, en este ejemplo, hay dos situaciones cuando un byte de prevención de la emulación puede ser insertado. La primera situación se produce cuando los datos emularande modo accidental un código inicial o un prefijo del código inicial. La segunda situación se produciría cuando los datos emularan de manera accidental los datos que hubieran tenido insertados un byte de prevención de la
emulación.

En cualquier caso, el descodificador puede simplemente buscar el patrón adecuado, descartar el byte de prevención de la emulación, y procesar los datos como de costumbre.

\newpage

Para evitar el procesamiento expuesto de una manera más programática, considérese lo siguiente. Sobre el lado del codificador, para enviar un paquete P6 de B bytes, a partir de un prefijo de código inicial compuesto por N, o más bytes del mismo valor W y un último byte de un valor diferente X, seguido por un sufijo del tipo de código inicial de identificación de 1 byte con el valor Y, se opera el siguiente proceso de pseudocódigo el cual inserta unos bytes de prevención de la emulación con el valor Z (donde W, X, Y y Z tienen valores diferentes entre sí, y P [B - 1] no es igual a W), donde la cantidad de datos suplementarios que enviar para llenar el canal se especifica mediante
E:

\vskip1.000000\baselineskip

1

\vskip1.000000\baselineskip

En el pseudocódigo anterior, se supone que una función "enviar_byte()" opera la transmisión de una unidad de datos (proceso 108 de la Fig. 1).

\newpage

En el lado del descodificador, para recibir el paquete, supóngase que el descodificador ha ya encontrado, leído y descartado el prefijo de código inicial conocido el cual se compone de N o más bytes del mismo valor W y de un último byte de un valor diferente X. Supóngase, así mismo, que se desea leer el sufijo tipo código inicial de byte simple desconocido en una variable Y y leer el paquete de los datos de carga útil en una matriz P[ ] y determinar la cantidad de datos de carga útil y situar la identificación de la cantidad en una variable B, mientras se suprimen los bytes de prevención de la emulación que tengan el valor Z (donde W, X, Y y Z tienen valores diferentes entre sí, y P [B-1] no es igual a W):

2

En el pseudocódigo anterior, una función "recibir_byte()" se supone que opera la recepción de una unidad de datos y una función "más_datos()" se supone que determina si hay cualquier unidad de datos más que deba ser recibida (comprendiendo estas dos funciones el proceso 114 de la Fig. 1).

El procedimiento descrito anteriormente posibilita el relleno de una cantidad arbitraria de un valor W antes del código inicial. Son igualmente posibles otras formulaciones que fijen los prefijos del número del valor W en N.

\vskip1.000000\baselineskip

Segundo Procedimiento Ejemplar

El procedimiento que va a ser descrito ilustra un último ejemplo específico distinto del procedimiento mostrado y descrito en la Fig. 1. Aquí, el procedimiento inserta un byte de datos de prevención de la emulación siempre que una cadena de bytes N de datos de carga útil se corresponda con los primeros N bytes del prefijo del código inicial, con independencia del valor de los datos de carga útil subsecuentes. Utilizando la nomenclatura del ejemplo anterior, si los datos contienen el patrón "WW" seguido de cualquier cosa, el procedimiento inserta un byte de prevención de la emulación. De acuerdo con ello, cuando el codificador identifica el patrón WW, inserta un byte de prevención de la emulación para proporcionar el siguiente patrón:

: WWZ

\vskip1.000000\baselineskip

La distinción entre el primer procedimiento descrito y el descrito inmediatamente antes es que el primer procedimiento examina los primeros bytes N +1 para determinar dónde se inserta un byte de prevención de la emulación, mientras que el procedimiento descrito inmediatamente antes examina los primeros bytes N.

El primer procedimiento reduce la cantidad de datos suplementarios que deben ser transmitidos, mientras que el procedimiento descrito inmediatamente antes opera utilizando reglas más simples. De esta manera, ambos procedimientos en conjunto ofrecen una elección entre reducir la cantidad de datos transmitidos y reducir la complejidad de la norma. Con el procedimiento descrito en primer término, la cantidad de datos se reduce con respecto a la del segundo procedimiento descrito. En el segundo procedimiento descrito, se utilizan reglas más simples.

Para ilustrar el procesamiento anterior de una manera más programática, considérese lo siguiente. En el lado del codificador, para enviar un paquete P [ ] de B bytes, empezando con un prefijo de código inicial, el cual se compone exactamente de N bytes del mismo valor W y un último byte de un valor diferente X, seguido por un sufijo tipo de código inicial de identificación de 1 byte con el valor Y, se opera el siguiente proceso de pseudocódigo el cual inserta unos bytes de prevención de la emulación con el valor Z (donde W, X, Y y Z tienen valores diferentes entre sí, y P
[B -1] no es igual a W).

\vskip1.000000\baselineskip

3

\vskip1.000000\baselineskip

En el pseudocódigo anterior, una función "enviar_byte()" se supone que opera la transmisión de una unidad de datos (proceso 108 de la Fig. 1).

\newpage

En el lado del descodificador, para recibir el paquete, supóngase que el descodificador ha ya encontrado, leído y descartado el prefijo de código inicial conocido, el cual se compone exactamente de N bytes del mismo valor W, y un último byte de un valor diferente X, y que se desea leer el sufijo tipo código inicial de byte simple desconocido en una variable Y para leer el paquete de datos de carga útil en una matriz P [ ] y determinar la cantidad de datos de carga útil y situar la indicación de la cantidad en una variable B, mientras se suprimen los bytes de prevención de la emulación que tengan el valor Z (donde W, X, Y y Z tienen valores diferentes entre sí, y P [B - 1] no es igual a W):

5

\vskip1.000000\baselineskip

En el pseudocódigo anterior una función "recibir_byte()" se supone que opera la recepción de una unidad de datos y una función "más_datos()" se supone que determina si hay alguna unidad más de datos que deba ser recibida (comprendiendo estas dos funciones el proceso 114 de la Fig. 1).

Se cree que los procedimientos descritos arriba ampliarán la cantidad de un número elevado de datos de carga útil de entrada aleatorios ideales mediante un factor, de modo aproximado, 1/256^{N} para el segundo procedimiento descrito 11256^{(N-1)} para el primer procedimiento descrito. Estas cantidades son pequeñas si N es de gran tamaño (por ejemplo, 2 o mayor, advirtiéndose que N = 2 para códigos iniciales del MPEG-2. El factor de expansión en el peor de los supuestos para la carga útil se cree que es 1/N para el segundo procedimiento descrito y 1/(N +1) para el primer procedimiento descrito. Si N se incrementa, el factor de expansión de carga útil se reduce tanto en el análisis estadístico como en el del peor de los supuestos (aunque la cantidad de datos utilizados por los propios códigos iniciales se incremente).

Debe apreciarse que el proceso de prevención de la emulación descrito con anterioridad no depende de saber cuántos datos existen en el paquete antes de empezar a enviarlos. Por tanto, ello no supone un retardo considerable.

Esta formulación del segundo procedimiento descrito parte de la base de que los bytes de prevención de la emulación insertados son bytes simples que tienen el valor Z. En su lugar es posible utilizar cualquier valor o valores múltiples o unas cadenas de valores para los datos de prevención de la emulación, siempre que el primer byte de datos insertados sea igual a W o X, lo que emularía un código inicial válido o parecería una continuación del inicio del prefijo.

Se puede incluso acarrear información en estos bytes de emulación de prevención (como por ejemplo una ID de trama de GOB de estilo H.263/número de secuencias de imágenes, o quizás fijar justo el MSB en "1" y utilizar los otros siete bytes para transmitir un carácter ASCII).

Si se considera lo que sucede al final del paquete en el lado del descodificador, se comprende que es más fácil controlar la operación si el último byte de la carga útil del paquete de datos no es W. Esto significa que el último byte enviado antes de un código inicial nunca necesitará ser un byte de prevención de la emulación y que un límite detectable puede ser situado por el descodificador entre el final de los datos de carga útil y el inicio de la secuencia de bytes igual a W para el siguiente código inicial. Forzar que este sea el caso puede, así mismo, permitir que se rellene con cualquier cantidad de bytes W (por ejemplo, bytes de cero) después del final de la carga útil y antes del siguiente código inicial sin perder el rastro de dónde se encuentra el final de la carga útil.

Relleno de Datos

Normalmente, en datos de vídeo, los datos que son enviados como carga útil de datos pueden no ser un número entero de bytes. Por ejemplo, se pueden tener 627 bits que deben ser enviados entre dos códigos iniciales. El nivel del sistema multiplex puede, sin embargo, operar en bytes. Ello es así para las condiciones del MPEG-2. Otras razones, como por ejemplo la posibilidad de detección de algunos patrones falsos del código inicial generados por errores de la transmisión o que posibiliten procesos de descodificación simples para el contenido de los datos del principio de la carga útil, pueden también justificar el deseo de que un paquete contenga un número entero de unidades de datos, como por ejemplo bytes. De esta forma, uno puede tener que enviar algunos datos más con el fin de acarrear los 627 bytes de datos. La cuestión entonces consiste en como entresacar los datos para que constituyan un número entero de bytes.

Hay otras situaciones en las que sería útil enviar datos de relleno suplementarios. Por ejemplo si un canal tiene una capacidad de 1 Megabyte/seg y la cantidad de datos de carga útil que debe ser enviada es de solo 900 Kbits/seg puede necesitarse o requerirse completar el canal con datos de relleno.

De acuerdo con una forma de realización, una técnica de relleno de datos permite que unos datos suplementarios sean añadidos al canal para, en esencia, rellenar los datos de carga útil.

La Fig. 2 es un diagrama de flujo que describe las etapas de un procedimiento de relleno de datos de acuerdo con una forma de realización en la cual los códigos iniciales se supone que empiezan con una cadena de bytes igual a cero. La etapa 200 establece la localización del final de los datos que se pretende enviar. La etapa 202 inserta un byte "1" después del último bit de los datos de carga útil. La etapa 204 determina el número de bits adicionales requerido para enviar un número entero de bytes. La etapa 206 inserta el número requerido de bits "0" después del bit insertado "1". La etapa 208 añade cualquier número deseado de bytes de los datos de relleno. Los datos de relleno pueden consistir en cualquier patrón de datos diseñado para evitar la confusión respecto de las localizaciones de los datos de carga útil auténticos y de los códigos iniciales intencionados. Esto se implementa típicamente mediante la inserción de bytes de valor "0".

A modo de ejemplo, considérese lo siguiente. Supóngase que deben ser enviados 627 bits. Aquí, la etapa 202 insertaría un bits de "1" después del bit sexagésimo vigésimo séptimo. La etapa 204 determinaría entonces que se requieren cuatro bits más para conseguir un número entero de bytes, aquí 79 bytes. De acuerdo con ello, la etapa 206 insertaría cuatro bits de "0" o 0000 después del bit "1" insertado. A continuación, después de establecer un número entero de bytes, la etapa 208 puede, si así se desea, añadir cualquier número deseado de bytes de datos de relleno. En este concreto ejemplo, pueden ser insertados bytes con un valor de 0. Los datos de relleno pueden ser utilizados simplemente como datos de relleno, o para otra finalidad, como por ejemplo contener información que un descodificador puede utilizar con alguna finalidad.

A continuación, considérese la situación en el descodificador. El descodificador recibe los datos rellenados y puede comenzar al final de los datos y apreciar hacia atrás los datos. Todos los bytes que el descodificador inicialmente vea serán los bytes 0 hasta que llegue al byte con el bit "1". El bit "1" muestra al codificador la localización del final de los datos de carga útil o reales. De esta manera, una vez que el descodificador encuentra el bit "1" que fue insertado, puede determinar con exactitud dónde terminan los datos reales.

De esta manera, las técnicas descritas con anterioridad pueden ser utilizadas para "redondear" el numero de bits que fueron enviados para que el numero de bits que son enviados consistan en un número entero de unidades de datos. Así mismo, estas técnicas pueden ser utilizadas para rellenar datos de relleno entre códigos iniciales que designen el inicio de los datos de carga útil.

Entorno Informático Ejemplar

La Fig. 3 ilustra un ejemplo de un entorno informático apropiado 300 sobre el cual puede ser implementado el sistema y los procedimientos relacionados descritos con anterioridad.

Debe apreciarse que el entorno informático 300 es solo un ejemplo de un entorno informático apropiado y no pretende proponer limitación alguna en cuanto al alcance de uso o funcionalidad del sistema de codificación/descodifica-
ción anteriormente descrito. Como tampoco debe ser interpretado en el sentido de que dependa de algún modo o exija cualquier requisito relacionado con uno cualquiera o con una combinación de los componentes ilustrados en el entorno informático ejemplar 300.

Las diversas formas de realización descritas pueden ser operativas con otros numerosos entornos o configuraciones de sistemas informáticos de propósito general o de propósito especial. Ejemplos de sistemas, entornos y/ o configuraciones informáticas que pueden ser apropiadas para su uso con el sistema de procesamiento de medios incluyen pero no se limitan a, las computadoras personales, las computadoras de servidor, los clientes simples, los clientes complejos, los dispositivos de mano o portátiles, los sistemas de microprocesador, los sistemas basados en microprocesador, los transdescodificadores, los sistemas electrónicos de consumidor programables, los PCs de red, las microcomputadoras, las grandes computadoras, los entornos informáticos distribuidos que incluyan cualquiera de los sistemas o dispositivos relacionados, y similares.

En ciertas implementaciones, el sistema y los procedimientos relacionados pueden ser perfectamente descritos en el contexto general de las instrucciones ejecutables por computadora, como por ejemplo, módulos de programa que sean ejecutados por una computadora. En general, los módulos de programa incluyen rutinas, programas, objetos, componentes, estructuras de datos, etc. que lleven a cabo tareas concretas o implementen tipos de datos abstractos concretos. Las formas de realización pueden, así mismo, llevarse a la práctica en entornos informáticos distribuidos en los que las tareas sean llevadas a cabo mediante dispositivos de procesamiento distantes que estén unidos mediante una red de comunicaciones. En un entorno informático distribuido, los módulos de programas pueden estar situados tanto en medios de almacenamiento informáticos locales como distantes, incluyendo dispositivos de almacenamiento de memoria. Los componentes del sistema informático descrito pueden ser utilizados para implementar un codificador y un descodificador que funcione de acuerdo con lo descrito con anterioridad.

De acuerdo con la forma de realización ilustrada de la Fig. 3, el sistema informático 300 se muestra incluyendo uno o más procesadores o unidades de procesamiento 302, una memoria 304 del sistema y un bus 306 que acopla los diversos componentes del sistema, incluyendo la memoria 304 del sistema, al procesador 302.

El bus 306 está destinado a representar uno o más de los diversos tipos de estructuras de bus, incluyendo un bus de memoria o controlador de memoria, un bus periférico, un puerto de gráficos acelerados, y un bus de procesador o local que utilice cualquiera de las diversas arquitecturas de bus. A modo de ejemplo, y no de limitación, dichas estructuras incluyen el bus de la Arquitectura Estándar del Sector Informático (ISA), el bus de la Arquitectura Microcanal (MCA), el bus de ISA Ampliado (EISA), el bus de la Asociación de Normalización de Electrónica de Vídeo (VESA) local, y el bus de Interconexión de Componentes Periféricos (PCI), también conocido como bus Mezzanine.

La computadora 300 típicamente incluye una diversidad de medios legibles por computadora. Dichos medios pueden consistir en cualquier medio disponible al que pueda accederse localmente y/o a distancia mediante la computadora 300, e incluye medios tanto volátiles como no volátiles, medios cambiables como no cambiables.

La Fig. 3, la memoria 304 del sistema incluye unos medios legibles por computadora en forma de memoria volátil como por ejemplo una memoria de acceso aleatorio (RAM) 310 y/o una memoria no volátil, como por ejemplo la memoria de solo lectura (ROM) 308. Un sistema básico de entrada/salida (BIOS) 312, que contiene las rutinas básicas que ayudan a transferir información entre los elementos situados dentro de la computadora 300, como por ejemplo durante la puesta en marcha, es almacenado en la ROM 308. La RAM 310 típicamente contiene datos y/o módulos de programas a los que puede inmediatamente accederse y/o ser actualmente operados mediante la(s) unidad(es) de procesamiento 302.

La computadora 300 puede, así mismo, incluir otros medios de almacenamiento por computadora cambiables/no cambiables, volátiles/no volátiles. Solo a modo de ejemplo, la Fig. 2 ilustra una unidad de disco duro 328 para su lectura a partir de o su escritura sobre unos medios magnéticos no cambiables, no volátiles (no mostrados y típicamente llamados "unidad de disco duro"), una unidad de disco magnético 330 para su lectura a partir de y su escritura sobre un disco magnético, no volátil 332 (por ejemplo, un "disco flexible"), y una unidad de disco óptico 334 para su lectura a partir de o su escritura sobre un disco óptico cambiable, no volátil 336, como por ejemplo un CD-ROM, un DVD-ROM, u otros medios ópticos. La unidad de disco duro 328, la unidad de disco magnético 330, y la unidad de disco óptico 334 están cada una conectada al bus 306 mediante una o más interfaces 326.

Las unidades y sus medios legibles por computadora asociados proporcionan un almacenamiento no volátil de las instrucciones legibles por computadora, estructuras de datos, módulos de programas, y otros datos destinados a la computadora 300. Aunque el entorno ejemplar descrito en la presente memoria emplea un disco duro 328, un disco magnético cambiable 332, y un disco óptico cambiable 336, debe apreciarse por parte de los expertos en la materia que pueden, así mismo, ser utilizados en el entorno operativo ejemplar otros tipos de medios legibles por computadora los cuales puedan almacenar datos a los que pueda accederse mediante una computadora, como por ejemplo casetes magnéticos, tarjetas de memoria Flash, discos de vídeo digitales, memorias de acceso aleatorio (RAMs), memorias de solo lectura (ROM), y similares.

Una pluralidad de módulos de programas pueden ser almacenados en el disco duro 328, el disco magnético 332, el disco óptico 336, la ROM 308 o la RAM 310, incluyendo, a modo de ejemplo y no de limitación, un sistema operativo 314, uno o más programas de aplicación 316 (por ejemplo, el programa de aplicación multimedia 324), otros módulos de programas 318 y los datos de programas 320. Un usuario puede introducir comandos e información en la computadora 300 a través de unos dispositivos de entrada, como por ejemplo un teclado 338 y un dispositivo de señalización 340 (como por ejemplo un "ratón"). Otros dispositivos de entrada pueden incluir un(os) dispositivo(s)
de audio/vídeo 353, un micrófono, una palanca, una tableta de juegos, una parabólica, un puerto serie, un escáner, o dispositivos similares (no mostrados). Estos y otros dispositivos de entrada están conectados a la(s) unidad(es) de procesamiento 302 a través de una(s) interfaz(ces) de entrada 342 que está(n) acoplada(s) al bus 306, pero pueden estar conectados por otras estructuras de interfaz y bus, como por ejemplo un puerto paralelo, un puerto para juegos o un bus serie universal (USB).

Un monitor 356 u otro tipo de dispositivo de visualización está también conectado al bus 306 por medio de una interfaz, como por ejemplo un adaptador de vídeo o una tarjeta de vídeo/gráficos 344. Además del monitor, las computadoras personales incluyen típicamente otros dispositivos de salida periféricos (no mostrados), como por ejemplo altavoces e impresoras, los cuales pueden estar conectados a través de la interfaz periférica de salida 346.

La computadora 300 puede operar en un entorno de conexión a red utilizando conexiones lógicas con una o más computadoras distantes, como por ejemplo una computadora distante 350. La computadora distante 350 puede incluir muchos o todos los elementos y características descritas en la presente memoria con respecto a la computadora.

Como se muestra en la Fig. 3, el sistema informático 300 está acoplado en comunicación con unos dispositivos distantes (por ejemplo, la computadora distante 350) a través de una red de área local (LAN) 351 y una red de área amplia general (WAN) 352. Dichos entornos de red son habituales en oficinas, redes informáticas de ámbito empresarial, intranets, e Internet.

Cuando se utiliza en un entorno informático de LAN, la computadora 300 está conectada a la LAN 351 mediante una interfaz o adaptador de red apropiado 348. Cuando se utilice en un entorno de conexión a red de WAN, la computadora 300 incluye un módem 354 u otro medio para establece comunicaciones a la WAN 352. El módem 354, el cual puede ser interno o externo, puede estar conectado al bus 306 del sistema por medio de la interfaz de entrada de usuario 342, o por otro mecanismo apropiado.

En un entorno de conexión a red, los módulos de programas relacionados con la computadora personal 300, o partes de éstos, pueden estar almacenados en un dispositivo de almacenamiento de memoria distante. A modo de ejemplo, y no de limitación, la Fig. 3 ilustra unos programas de aplicación distantes 316 que residen en un dispositivo de memoria de la computadora distante 350. Debe apreciarse que las conexiones a red mostradas y descritas son ejemplares y que pueden ser utilizados otros medios de establecer un enlace de comunicaciones entre las computadoras.

Conclusión

Algunos de los procedimientos y sistemas descritos en las líneas anteriores pueden proporcionar una prevención de la emulación de código inicial en un nivel de procesamiento distinto del nivel de bit. Esto es ventajoso porque puede aligerar las complejidades del procesamiento. Las técnicas descritas en el presente documento pueden ser empleadas en cualquier contexto apropiado, por ejemplo en conexión con una carga útil que incorpore el contenido creado mediante códigos de longitud variable, códigos Huffman y codificaciones aritméticas. Así mismo, algunas formas de realización proporcionan un método directo para el relleno de datos que pueda asegurar que un número entero de bytes sea enviado cuando se desee y que pueda posibilitar el envío de datos de relleno adicionales además de los datos con destino a los códigos iniciales, a los patrones de emulación de la prevención y a los datos de carga útil básicos.

Aunque la invención ha sido descrita en un lenguaje específico para las características estructurales y/ o las etapas metodológicas, debe entenderse que la invención definida en las reivindicaciones adjuntas, no está necesariamente limitada a las características o etapas específicas descritas. Por el contrario, las características y etapas específicas se divulgan como formas preferentes de reivindicar la invención reivindicada.

Claims

```
\global\parskip0.950000\baselineskip
```
1. En un descodificador, un procedimiento que comprende:

el relleno de una carga útil de datos en un flujo de datos con uno o más bits de relleno;

estando el procedimiento caracterizado por:

la inserción de uno o más bits de relleno después de la carga útil de datos en los datos rellenados, en el que la inserción de los uno o más bits de relleno incluye:

la inserción (202) de un bit de 1 después de la carga útil de datos;

la inserción (206) de cualquier bit de 0 después del bit de 1, en el que el número de bits insertados varía dependiendo del número de bits existentes en la carga útil de datos, de manera que los datos rellenados consisten en un número entero de bytes (204) que finaliza con un byte de no cero que incluye los uno o más bits de relleno y de tal manera que el byte de no cero que incluye los uno o más bits de relleno difiere de un primer byte de un código inicial y, de esta forma, facilita la prevención de la emulación del código inicial;

comprendiendo el procedimiento la inserción (208) uno o más bytes iguales a 0 x 00 después del byte de no cero que finaliza los datos rellenados y antes del código inicial.
```
\vskip1.000000\baselineskip
```
2. El procedimiento de la reivindicación 1 que comprende así mismo la inserción del código inicial en el flujo de datos después de los uno o más bytes iguales a 0 x 00.
3. El procedimiento de la reivindicación 1 en el que la carga útil de datos es una de varias cargas útiles de datos, comprendiendo así mismo el procedimiento, para cada uno de la o de las otras diversas cargas útiles de datos, la repetición para la otra carga útil de datos de la inserción de uno o más bits de relleno y la inserción de uno o más bytes iguales a 0 x 00, en el que el número de bits de cero insertados es diferente para al menos dos de las diversas cargas útiles de datos.
4. El procedimiento de cualquiera de las reivindicaciones 1 a 3, en el que el primer byte del código inicial está en un prefijo del código inicial.
5. El procedimiento de la reivindicación 4, en el que el prefijo del código inicial empieza con una cadena de varios consecutivos bits de cero, de manera que cualquier bit de cero de los uno o más bytes de relleno tienen el mismo valor que los bits del primer byte del código inicial, de manera que los uno o más bytes iguales a 0 x 00 tienen el mismo valor que el primer byte del código inicial.
6. El procedimiento de la reivindicación 5, en el que el prefijo del código inicial consiste en una cadena de varios consecutivos bits de cero seguida inmediatamente por un bit de cero.
7. El procedimiento de la reivindicación 5, en el que el prefijo del código de inicio consiste en dos bytes cada uno igual a 0 x 00 seguido inmediatamente por un byte igual a 0 x 01.
8. El procedimiento de cualquiera de las reivindicaciones 1 a 7, en el que los datos rellenados comprenden datos de vídeo.
9. El procedimiento de la reivindicación 1 en el que la prevención de la emulación del código inicial incluye:

la búsqueda de la carga útil de datos para un patrón del código inicial; y

si el patrón se encuentra, la inserción de un byte de prevención de la emulación del código inicial en la carga útil de datos para prevenir la emulación del código inicial.
```
\vskip1.000000\baselineskip
```
10. En un descodificador, un procedimiento que comprende:

la recepción de los datos rellenados que comprenden una carga útil de datos y uno o más bits de relleno; y

la localización de la carga útil de datos en los datos rellenados;

estando el procedimiento, caracterizado por:

la detección de uno o más bytes iguales a 0 x 00 que fueron insertados (208) después de un byte de no cero que finaliza los datos rellenados y antes de un código inicial que comienza una carga útil de datos siguiente;
```
\global\parskip1.000000\baselineskip
```
la búsqueda para los uno o más bits de relleno en los datos rellenados, consistiendo los uno o más bits de relleno en:

un bit de 1 que fue insertado (202)

cualquiera de cero a siete bits de 0 que fueron insertados (206) después del bit de 1 para proporcionar un número entero de bytes en los datos rellenados, en el que el número de bits de cero insertados varía dependiendo del número de bits existente en la carga útil de datos, en el que los datos rellenados consisten en un número entero de bytes que termina con el byte de no cero que incluye los uno o más bits de relleno, y en el que el byte de no cero que incluye los uno o más bits de relleno difiere de un primer byte del código inicial y, de esta forma, facilita la prevención de la emulación del código inicial.
11. El procedimiento de la reivindicación 10 que comprende así mismo el descarte de uno o más bytes iguales a 0 x 00 y de los uno o más bits de relleno.
12. El procedimiento de las reivindicaciones 10 u 11 que comprende así mismo la recepción del código inicial después de los uno o más bytes iguales a 0 x 00.
13. El procedimiento de la reivindicación 10 en el que la carga útil de datos es una de las diversas cargas útiles de datos, comprendiendo así mismo el procedimiento, para cada una o más de las otras cargas útiles de datos de las diversas cargas útiles de datos, la repetición para las otras cargas útiles de datos la localización, la detección y la búsqueda, en el que el número de bits insertados es diferente para al menos dos de las diversas cargas útiles de datos.
14. El procedimiento de la reivindicación 13 en el que el primer byte del código inicial está en un prefijo del código inicial.
15. El procedimiento de la reivindicación 14 en el que el prefijo del código inicial comienza con una cadena de varios consecutivos bits de cero, en el que cualquier bit de cero de los uno o más bits de relleno tienen el mismo valor que los bits del primer byte del código inicial y los uno o más bytes iguales a 0 x 00 tienen el mismo valor que los bits del primer byte del código inicial.
16. El procedimiento de la reivindicación 15 en el que el prefijo del código inicial consiste en una cadena de varios consecutivos bits de cero seguida inmediatamente por un bit de 1.
17. El procedimiento de la reivindicación 16 en el que el prefijo de código del inicio consiste en 2 bytes cada uno igual a 0 x 00 seguido inmediatamente por un byte igual a 0 x 01.
18. El procedimiento de cualquiera de las reivindicaciones 10 a 17 en el que los datos rellenados comprenden datos de vídeo.
19. El procedimiento de la reivindicación 10 que comprende:

la búsqueda de la carga útil de datos para un byte de emulación del código inicial que previene la emulación del código inicial; y

si se encuentra el byte de emulación del código inicial, la supresión del byte de prevención de la emulación del código inicial respecto de la carga útil de datos.
```
\vskip1.000000\baselineskip
```
20. Uno o más medios legibles por computadora que tienen almacenados en ellos unas inserciones ejecutables por computadora para determinar que una computadora lleve a cabo el procedimiento de una de las reivindicaciones 1 a 9 o 10 a 19.
21. Un codificador adaptado para llevar a cabo el procedimiento de cualquiera de las reivindicaciones 1 a 9.
22. Un descodificador adaptado para llevar a cabo el procedimiento de cualquiera de las reivindicaciones 10 a 19.