ejemplo de análisis de flujo binario ac-3€¦ · ing. j. daniel rodríguez vega página 3 de 19

19
Ing. J. Daniel Rodríguez Vega Página 1 de 19 [email protected] http://danielr-be.jimdo.com/ Ejemplo de análisis de flujo binario AC-3 Ing. J. Daniel Rodríguez Vega Introducción Se reportó un problema relacionado con el audio Dolby Digital de un canal de televisión digital terrestre. El problema consiste en que, ocasionalmente, el sistema de compresión no puede procesar el flujo binario AC-3. Dicho flujo es multiplexado en una señal de video en banda base, la cual se transporta por medio de una línea de servicio hacia el departamento de compresión. Una primera revisión del audio Dolby Digital no arrojó ningún resultado que indicase algún problema grave y obvio. Por tal motivo, se decidió hacer un análisis mucho mas detallado del flujo binario, basándose para ello en los estándares ATSC y SMPTE que definen la trama de sincronización AC-3, y su formato y transporte en la interfaz AES3. El flujo binario AC-3 El estándar ATSC A/52:2012 define el flujo binario AC-3 como una secuencia de tramas básicas llamadas tramas de sincronización (figura 1). Figura 1. Trama de sincronización AC-3 (syncframe). Cada trama es de naturaleza auto contenida, es decir, incluye todos los elementos necesarios para realizar el proceso de decodificación. La trama de sincronización es, por lo tanto, el componente más pequeño que se puede resolver, y consiste de: 1) Un encabezado con información de sincronización (SI – Synchronization Information). Contiene una palabra de sincronización, la especificación de la frecuencia de muestreo y el tamaño de la trama. Todos estos elementos son necesarios para adquirir y mantener la sincronización del flujo binario. 2) Un bloque de información que describe el flujo binario (BSI – Bit-Stream Information). Aquí se incluyen, entre otros elementos, el número de canales codificados, el nivel de los diálogos y la información del tipo de servicio.

Upload: others

Post on 30-Apr-2020

3 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: Ejemplo de análisis de flujo binario AC-3€¦ · Ing. J. Daniel Rodríguez Vega Página 3 de 19

Ing. J. Daniel Rodríguez Vega Página 1 de 19 [email protected] http://danielr-be.jimdo.com/

Ejemplo de análisis de flujo binario AC-3 Ing. J. Daniel Rodríguez Vega

Introducción Se reportó un problema relacionado con el audio Dolby Digital de un canal de televisión digital terrestre. El problema consiste en que, ocasionalmente, el sistema de compresión no puede procesar el flujo binario AC-3. Dicho flujo es multiplexado en una señal de video en banda base, la cual se transporta por medio de una línea de servicio hacia el departamento de compresión. Una primera revisión del audio Dolby Digital no arrojó ningún resultado que indicase algún problema grave y obvio. Por tal motivo, se decidió hacer un análisis mucho mas detallado del flujo binario, basándose para ello en los estándares ATSC y SMPTE que definen la trama de sincronización AC-3, y su formato y transporte en la interfaz AES3.

El flujo binario AC-3 El estándar ATSC A/52:2012 define el flujo binario AC-3 como una secuencia de tramas básicas llamadas tramas de sincronización (figura 1).

Figura 1. Trama de sincronización AC-3 (syncframe).

Cada trama es de naturaleza auto contenida, es decir, incluye todos los elementos necesarios para realizar el proceso de decodificación. La trama de sincronización es, por lo tanto, el componente más pequeño que se puede resolver, y consiste de:

1) Un encabezado con información de sincronización (SI – Synchronization Information). Contiene una palabra de sincronización, la especificación de la frecuencia de muestreo y el tamaño de la trama. Todos estos elementos son necesarios para adquirir y mantener la sincronización del flujo binario.

2) Un bloque de información que describe el flujo binario (BSI – Bit-Stream Information). Aquí se

incluyen, entre otros elementos, el número de canales codificados, el nivel de los diálogos y la información del tipo de servicio.

Page 2: Ejemplo de análisis de flujo binario AC-3€¦ · Ing. J. Daniel Rodríguez Vega Página 3 de 19

Ing. J. Daniel Rodríguez Vega Página 2 de 19 [email protected] http://danielr-be.jimdo.com/

3) Seis bloques de datos de audio (ABn – Audio Block n). Cada bloque representa 256 muestras PCM nuevas, por lo que cada trama AC-3 representa 1536 muestras. La información necesaria para la decodificación puede ser compartida por varios bloques a la vez, y dicha información sólo se codifica en el primer bloque que la utiliza. El decodificador usa nuevamente esta información para decodificar apropiadamente los bloques posteriores. La información que se comparte dentro de una misma trama siempre se incluye en el primer bloque, lo cual le permite al decodificador empezar a trabajar de inmediato.

4) Un bloque de datos auxiliares opcionales (AUX). Estos datos se utilizan para incluir información

adicional que pudiese encontrarse a continuación del último bloque de audio.

5) Un elemento para revisión de redundancia (CRC). Contiene dos palabras para revisión de error. Una para cubrir los primeros 5/8 de la trama, y la segunda para la revisión de la trama completa.

El estándar ATSC A/52:2012 especifica la sintaxis para un flujo binario AC-3 tal y como se muestra en la tabla 1.

Tabla 1. Sintaxis para un flujo binario AC-3.

Sintaxis Bits AC-3_bitstream() { while(true) { syncframe(); } } /* end of AC-3 bit stream */

© Advanced Television Systems Committee. 2012.

Y la sintaxis que define a la trama de sincronización se especifica tal y como se muestra en la tabla 2.

Tabla 2. Especificación de sintaxis para una trama de sincronización AC-3.

Sintaxis Bits syncframe() { syncinfo(); bsi(); for (blk = 0; blk < 6; blk++) { audblk(); } auxdata(); errorcheck(); } /* end of syncframe */

© Advanced Television Systems Committee. 2012.

Page 3: Ejemplo de análisis de flujo binario AC-3€¦ · Ing. J. Daniel Rodríguez Vega Página 3 de 19

Ing. J. Daniel Rodríguez Vega Página 3 de 19 [email protected] http://danielr-be.jimdo.com/

La figura 2 ilustra, a nivel lógico, el flujo binario AC-3, en conformidad con la sintaxis especificada en las tablas 1 y 2.

Figura 2. Flujo binario AC-3.

En el flujo serial, el orden de recepción de la información es con el bit mas significativo (MSB) llegando primero.

Estándares en los que se basa el presente análisis de flujo binario AC-3 El estándar ATSC A/52:2012 define el esquema de compresión de audio digital AC-3 (Dolby Digital). El flujo AC-3 es transportado por medio de la interfaz de audio digital AES3 (estándar AES3-2-2009, r2014), siguiendo para ello los lineamientos del estándar SMPTE ST 337. La señal de video en banda base, que incluye el flujo binario de interés, se transporta por medio de la interfaz SMPTE ST 292, la cual deriva el flujo AC-3 a partir de la interfaz AES3, y le da formato en conformidad con los lineamientos del estándar SMPTE ST 299. El formato de los paquetes de audio que se analizaron esta definido en el estándar SMPTE ST 291. Los requerimientos específicos para el transporte de un flujo binario AC-3 en la interfaz AES3, están descritos en los estándares SMPTE ST 338, SMPTE ST 339 y SMPTE ST 340. Los estándares mencionados constituyen la base del análisis incluido en el presente documento.

Procedimiento de análisis

1) Se toma una muestra aleatoria de la señal de video en banda base. La muestra consiste en la captura de toda la información numérica correspondiente a un único cuadro de video.

2) A partir de los datos numéricos de la muestra, se aísla el flujo Cb/Cr de la señal de video, para así

poder identificar los paquetes SMPTE ST 291 que se encuentran en el área de datos auxiliares de cada línea digital 1080i 59.94 (muestra 1924 a la muestra 2195 – ver figura 3).

Page 4: Ejemplo de análisis de flujo binario AC-3€¦ · Ing. J. Daniel Rodríguez Vega Página 3 de 19

Ing. J. Daniel Rodríguez Vega Página 4 de 19 [email protected] http://danielr-be.jimdo.com/

Figura 3. La línea digital 1080i 59.94, compuesta por 2200 muestras.

3) Se identifican y se extraen algunos paquetes SMPTE ST 291 (figura 4) que transportan el flujo binario de interés. Se extraen en particular aquellos paquetes que contienen los preámbulos SMPTE ST 337 y los campos SI y BSI de la trama de sincronización AC-3.

Figura 4. Paquete de datos SMPTE ST 291, con información de audio en formato definido por el estándar SMPTE ST 299.

4) Se decodifican los paquetes SMPTE ST 291 para identificar el comienzo de las tramas de sincronización, y para revisar, a nivel básico, las características e integridad del flujo AC-3.

Descripción y análisis del flujo AC-3 El flujo binario tiene las siguientes características elementales:

Formato Dolby: 32-bit Modo de canal: 3/2L Tasa de transmisión de datos: 384 kbps Frecuencia de muestreo: 48 kHz

En el cuadro de video capturado SE DETECTARON DOS RÁFAGAS SMPTE ST 337. En el presente documento, se hace referencia a dichas ráfagas mediante los nombres “ráfaga #1” y “ráfaga #2”. Se identificó correctamente el comienzo de la trama de sincronización AC-3.

Análisis de la ráfaga #1 Las palabras del preámbulo tienen los valores siguientes: Pa = 0xF872 Pb = 0x4E1F Pc = 0xE002 Pd = 0x0060

Page 5: Ejemplo de análisis de flujo binario AC-3€¦ · Ing. J. Daniel Rodríguez Vega Página 3 de 19

Ing. J. Daniel Rodríguez Vega Página 5 de 19 [email protected] http://danielr-be.jimdo.com/

La figura 5 ilustra, en su totalidad, la ráfaga #1, decodificada a partir de los paquetes SMPTE ST 291. En color azul se resalta el preámbulo (burst_preamble), el cual muestra un formato en modo de cuadro (frame mode). En color rosa se resalta la carga útil de la ráfaga (burst_payload). Las palabras de datos están numeradas (0–8).

Figura 5. Ráfaga #1, transportada por la interfaz AES3.

Las palabras de sincronización Pa y Pb indican un modo de operación de 16 bits. La decodificación de la palabra Pc (burst_info) arroja la descripción de elementos que se muestra en la tabla 3.

Tabla 3. Decodificación de la palabra Pc (burst_info)

Campo Valor decodificado data_stream_number 7

data_type_dependent 00000

error_flag data may be valid

data_mode 16-bit mode

data_type time stamp data

Los campos data_stream_number y data_type indican que la ráfaga #1 contiene una estampa de tiempo con un formato especificado por el estándar SMPTE ST 339. La decodificación de la palabra Pd (length_code) indicó una longitud de carga útil igual a 96 bits, o sea, 6 palabras de 16 bits. Sin embargo, se observó que la carga útil real de la ráfaga #1 es de 9 palabras de 16 bits (figura 5). Esto no representa en sí una falta de apego al estándar SMPTE ST 339, pero sí representa una clara discrepancia entre el valor de la palabra Pd y la longitud real de la carga útil. La longitud total de la ráfaga #1 es de 13 palabras de 16 bits, que se transportan en 7 tramas AES. La tabla 4 muestra el formato de la carga útil, en conformidad con las definiciones del estándar SMPTE ST 339.

Page 6: Ejemplo de análisis de flujo binario AC-3€¦ · Ing. J. Daniel Rodríguez Vega Página 3 de 19

Ing. J. Daniel Rodríguez Vega Página 6 de 19 [email protected] http://danielr-be.jimdo.com/

Tabla 4. Formato de la carga útil de la ráfaga #1

Palabra de estampa de tiempo MSB número de bit LSB

15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

0 Usr8, Usr7, flags, hours 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

1 Usr6, Usr5, flag, minutes 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

2 Usr4, Usr3, flag, seconds 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

3 Usr2, Usr1, cf, df, frames 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

4 Sample number 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

5 Reserved, flags 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1

6 User private (optional) 0 0 0 0 0 0 0 1 0 0 0 1 0 0 0 0

7 User private (optional) 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1

8 Delay (optional) 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

Observaciones

El bit de bandera f2 en la palabra 5 (bit 6), indica la presencia de información de código de tiempo (bit ajustado a un valor de “0”).

El valor “1” en el bit de bandera f1 de la palabra 5 (bit 1), indica que los campos en las palabras 0

a 3 han sido copiados de un código de tiempo SMPTE ST 12. Sin embargo, se observa que todos los campos tienen valores nulos.

La tasa de transmisión de cuadros no esta indicada (bits 5-2 de la palabra 5).

El bit 0 de la palabra 5 contiene la bandera drop-frame del código de tiempo SMPTE ST 12, la cual

tiene aquí un valor de “1”. Dicho valor esta indicando entonces la aplicación del esquema de conteo drop-frame.

El estándar SMPTE ST 339 establece que, si la bandera f1 se ajusta a un valor de “1”, entonces el

bit 6 de la palabra 3 también deberá contener la bandera drop-frame. En la ráfaga analizada, dicha bandera (ajustada a un valor de “1”), no está siendo indicada en la palabra 3. Por lo tanto, en este punto, el formato de la ráfaga #1 no está cumpliendo con los lineamientos del estándar SMPTE ST 339.

La palabra 4 tiene un valor nulo, lo que indicaría que la estampa de tiempo es seguida por una

ráfaga que no contiene audio codificado con baja tasa de transmisión. Sin embargo, éste no es el caso, pues la ráfaga #1 esta, de hecho, seguida por una ráfaga que contiene audio AC-3. Esto

constituye una clara discrepancia entre lo que establece el estándar SMPTE ST 339 y el formato de la ráfaga #1.

Las palabras 6 y 7, que son opcionales, no tienen valores nulos, pero se desconoce el significado de

la información que contienen.

La palabra 8 tiene el valor 0x8000, lo cual indica que no hay información de retraso, aún cuando la palabra está presente en la ráfaga. Esta opción es válida y esta contemplada dentro del estándar SMPTE ST 339.

Page 7: Ejemplo de análisis de flujo binario AC-3€¦ · Ing. J. Daniel Rodríguez Vega Página 3 de 19

Ing. J. Daniel Rodríguez Vega Página 7 de 19 [email protected] http://danielr-be.jimdo.com/

Análisis de la ráfaga #2

Las palabras del preámbulo tienen los valores siguientes: Pa = 0xF872 Pb = 0x4E1F Pc = 0x0001 Pd = 0x3000 La figura 6 ilustra un fragmento de la ráfaga #2, decodificada a partir de los paquetes SMPTE ST 291. En color azul se resalta el preámbulo (burst_preamble), el cual muestra un formato en modo de cuadro (frame mode). En color rosa se resalta el comienzo de la carga útil de la ráfaga (burst_payload), la cual contiene una trama de sincronización AC-3. No se ilustra la totalidad de la carga útil. Solo se muestran aquellas palabras que contienen los campos SI y BSI de la trama de sincronización AC-3.

Figura 6. Fragmento de la ráfaga #2, transportada por la interfaz AES3.

Las palabras de sincronización Pa y Pb indican un modo de operación de 16 bits. La decodificación de la palabra Pc (burst_info) arroja la descripción de elementos que se muestra en la tabla 5.

Tabla 5. Decodificación de la palabra Pc (burst_info)

Campo Valor decodificado

data_stream_number 0

data_type_dependent 00000

error_flag data may be valid

data_mode 16-bit mode

data_type ATSC A/52 (AC-3)

El campo data_type indica que la ráfaga #2 contiene una trama de sincronización AC-3. Los campos de la palabra Pc contienen valores que se apegan a los lineamientos del estándar SMPTE ST 340.

Page 8: Ejemplo de análisis de flujo binario AC-3€¦ · Ing. J. Daniel Rodríguez Vega Página 3 de 19

Ing. J. Daniel Rodríguez Vega Página 8 de 19 [email protected] http://danielr-be.jimdo.com/

La decodificación de la palabra Pd (length_code) indicó una longitud de la carga útil igual a 12,288 bits, lo cual equivale a 768 palabras de 16 bits, que se transportan en 384 tramas AES. La longitud total de la ráfaga #2 es, por lo tanto, igual a 772 palabras de 16 bits, las cuales se transportan en 386 tramas AES. Con fines de verificación, se analizaron y se decodificaron las seis palabras que corresponden a los campos SI y BSI de la trama de sincronización (figura 6). Los valores de las palabras son los siguientes: Palabra #1: 0x0B77 Palabra #2: 0x38C6 Palabra #3: 0x1C30 Palabra #4: 0xE1FC Palabra #5: 0x04E4 Palabra #6: 0x9200 La decodificación requiere el conocimiento de la sintaxis para los campos SI y BSI. Dicha sintaxis se especifica en las tablas 6, 7 y 8 (estándar ATSC A/52:2012).

Tabla 6. Especificación de sintaxis para el campo SI.

Sintaxis Bits syncinfo() { syncword crc1 fscod frmsizecod } /* end of syncinfo */

16 16 2 6

© Advanced Television Systems Committee. 2012.

Page 9: Ejemplo de análisis de flujo binario AC-3€¦ · Ing. J. Daniel Rodríguez Vega Página 3 de 19

Ing. J. Daniel Rodríguez Vega Página 9 de 19 [email protected] http://danielr-be.jimdo.com/

Tabla 7. Especificación de sintaxis para el campo BSI.

Sintaxis Bits bsi() { bsid bsmod acmod if((acmod & 0x1)&&(acmod != 0x1))/*if 3 front channels*/{cmixlev} if(acmod & 0x4) /* if a surround channel exists */{surmixlev} if(acmod == 0x2) /* if in 2/0 mode */{dsurmod} lfeon dialnorm compre if(compre) {compr} langcode if(langcode) {langcod} audprodie if(audprodie) { mixlevel roomtyp } if(acmod == 0)/* if 1+1 mode (dual mono, so some items need a second value)*/ { dialnorm2 compr2e if(compr2e) {compr2} langcod2e if(langcod2e) {langcod2} audprodi2e if(audprodi2e) { mixlevel2 roomtyp2 } { copyrightb origbs timecod1e if(timecod1e) {timecod1} timecod2e if(timecod2e) {timecod2} addbsie if(addbsie) { addbsil addbsi (addbsil+1) } } /* end of bsi */

5 3 3 2 2 2 1 5 1 8 1 8 1

5 2

5 1 8 1 8 1

5 2

1 1 1

14 1

14 1

6 8

© Advanced Television Systems Committee. 2012.

Page 10: Ejemplo de análisis de flujo binario AC-3€¦ · Ing. J. Daniel Rodríguez Vega Página 3 de 19

Ing. J. Daniel Rodríguez Vega Página 10 de 19 [email protected] http://danielr-be.jimdo.com/

Tabla 8. Sintaxis alternativa para el campo BSI.

Sintaxis Bits bsi() { bsid bsmod acmod if((acmod & 0x1)&&(acmod != 0x1))/*if 3 front channels*/{cmixlev} if(acmod & 0x4) /* if a surround channel exists */{surmixlev} if(acmod == 0x2) /* if in 2/0 mode */{dsurmod} lfeon dialnorm compre if(compre) {compr} langcode if(langcode) {langcod} audprodie if(audprodie) { mixlevel roomtyp } if(acmod == 0)/* if 1+1 mode (dual mono, so some items need a second value)*/ { dialnorm2 compr2e if(compr2e) {compr2} langcod2e if(langcod2e) {langcod2} audprodi2e if(audprodi2e) { mixlevel2 roomtyp2 } } copyrightb origbs xbsi1e if(xbsi1e) { dmixmod ltrtcmixlev ltrtsurmixlev lorocmixlev lorosurmixlev } xbsi2e if(xbsi2e) { dsurexmod dheadphonmod adconvtyp xbsi2 encinfo } addbsie if(addbsie) { addbsil addbsi (addbsil+1)x8 } } /* end of bsi */

5 3 3 2 2 2 1 5 1 8 1 8 1

5 2

5 1 8 1 8 1

5 2

1 1 1

2 3 3 3 3

1

2 2 1 8 1

1

6

© Advanced Television Systems Committee. 2012.

Page 11: Ejemplo de análisis de flujo binario AC-3€¦ · Ing. J. Daniel Rodríguez Vega Página 3 de 19

Ing. J. Daniel Rodríguez Vega Página 11 de 19 [email protected] http://danielr-be.jimdo.com/

La tabla 9 muestra la decodificación de los campos SI y BSI. La columna izquierda indica el número de paquete SMPTE ST 291 (DBN – Data Block Number) que incluye la correspondiente palabra de la trama de sincronización. Los bits se agrupan para definir los distintos elementos, en conformidad con la sintaxis establecida en el estándar ATSC A/52:2012.

Tabla 9. Decodificación de los campos SI y BSI de la trama de sincronización AC-3.

DBN 63 Palabra #1

CH1 0 B 7 7 0 0 0 0 1 0 1 1 0 1 1 1 0 1 1 1 syncword DBN 63 Palabra #2

CH2 3 8 C 6 0 0 1 1 1 0 0 0 1 1 0 0 0 1 1 0 crc1 DBN 64 Palabra #3

CH1 1 C 3 0 0 0 0 1 1 1 0 0 0 0 1 1 0 0 0 0 fscod frmsizecod bsid bsmod DBN 64 Palabra #4

CH2 E 1 F C 1 1 1 0 0 0 0 1 1 1 1 1 1 1 0 0 acmod cmixlev surmixlev lfeo

n

dialnorm com

pre

compr DBN 65 Palabra #5

CH1 0 4 E 4 0 0 0 0 0 1 0 0 1 1 1 0 0 1 0 0 compr lan

gcod

e

aud

pro

die

copyrightb

origb

s

xbsi1e

dmixmod ltrtcmixlev DBN 65 Palabra #6

CH2 9 2 0 0 1 0 0 1 0 0 1 0 0 0 0 0 0 0 0 0 ltrtsurmixlev lorocmixlev lorosurmixlev xb

si2e

add

bsie

Page 12: Ejemplo de análisis de flujo binario AC-3€¦ · Ing. J. Daniel Rodríguez Vega Página 3 de 19

Ing. J. Daniel Rodríguez Vega Página 12 de 19 [email protected] http://danielr-be.jimdo.com/

La tabla 10 presenta un resumen de todos los elementos correspondientes a los campos SI y BSI de la trama de sincronización analizada. La interpretación de cada código esta hecha en conformidad con el estándar ATSC A/52:2012.

Tabla 10. Interpretación de los elementos en los campos SI y BSI de la trama de sincronización AC-3. Elemento Código Interpretación

syncword 0000 1011 0111 0111 Palabra de sincronización para la trama AC-3

crc1 0011 1000 1100 0110 —

fscod 00 Frecuencia de muestreo: 48 kHz

frmsizecod 011100 Tasa binaria nominal: 384 kbps; número de palabras de 16 bits antes de la siguiente syncword: 768

bsid 00110 6; valor que indica el uso de la sintaxis alternativa para el flujo binario

bsmod 000 Servicio principal de audio: complete main (CM)

acmod 111 Modo de codificación de audio: 3/2; L, C, R, SL, SR; nfchans = 5

cmixlev 00 Nivel de mezcla para el canal central: 0.707 (-3.0 dB)

surmixlev 00 Nivel de mezcla para los canales envolventes: 0.707 (-3.0 dB)

lfeon 1 El canal de efectos de baja frecuencia (LFE) esta activo

dialnorm 11111 Normalización de diálogos: -31 dB

compre 1 Está presente una palabra de ganancia de compresión

compr 0000 0001 Palabra de ganancia de compresión

langcode 0 No existe código de idioma

audprodie 0 No existe información de producción de audio

copyrightb 1 La información en el flujo binario esta protegida por derechos de autor

origbs 1 El flujo binario es original

xbsi1e 1 Existe la información extra #1 del flujo binario

dmixmod 00 No se indica el tipo preferido de mezcla a estéreo (stereo downmix)

ltrtcmixlev 100 Nivel de mezcla Lt/Rt para el canal central: 0.707 (-3.0 dB)

ltrtsurmixlev 100 Nivel de mezcla Lt/Rt para los canales envolventes: 0.707 (-3.0 dB)

lorocmixlev 100 Nivel de mezcla Lo/Ro para el canal central: 0.707 (-3.0 dB)

lorosurmixlev 100 Nivel de mezcla Lo/Ro para los canales envolventes: 0.707 (-3.0 dB)

xbsi2e 0 No existe la información extra #2 del flujo binario

addbsie 0 No existe información adicional para el flujo binario

Observaciones

No se detectó ninguna irregularidad en los campos SI y BSI de la trama de sincronización AC-3.

Verificación de la tasa de repetición de las ráfagas de datos AC-3 Dado que se observó que las tramas de sincronización AC-3 están precedidas por una estampa de tiempo, se pensó que la presencia de dicha estampa estaba probablemente alterando de manera adversa la tasa de repetición de ráfagas AC-3 dentro del flujo. El documento SMPTE ST 340 define una tasa estándar de repetición igual a 1536 tramas AES. A una frecuencia de muestreo de 48 kHz, dicha tasa equivale a transmitir una ráfaga de datos AC-3 cada 32 milisegundos. Este concepto se ilustra en la figura 7.

Page 13: Ejemplo de análisis de flujo binario AC-3€¦ · Ing. J. Daniel Rodríguez Vega Página 3 de 19

Ing. J. Daniel Rodríguez Vega Página 13 de 19 [email protected] http://danielr-be.jimdo.com/

Figura 7. Tasa estándar de repetición de ráfagas AC-3.

Se considera que las ráfagas de datos para un flujo AC-3 ocurren a una tasa estándar de repetición, si los puntos de referencia para ráfagas consecutivas están espaciados por 1536 tramas AES. El estándar SMPTE ST 340 define el punto de referencia AC-3 como el bit 0 de la carga útil de la ráfaga SMPTE ST 337 (burst_payload). Este concepto se ilustra en la figura 8.

Figura 8. Punto de referencia AC-3.

Para verificar que la tasa de repetición AC-3 cumpliera con el estándar SMPTE ST 340, se procedió a hacer un análisis de los datos auxiliares transportados en los canales 1 y 2 del grupo de audio número 1 (SMPTE ST 299, DID = 0x2E7), que es el que transporta el flujo binario AC-3. Se buscó capturar una muestra que permitiese ubicar los puntos de referencia de por lo menos dos ráfagas SMPTE ST 337 que transportasen datos AC-3. Después de no pocos intentos, se logró capturar un cuadro de video que incluye los puntos de referencia buscados. La muestra analizada incluye una secuencia completa de las ráfagas #1 y #2, y la fracción de una secuencia previa contigua. La figura 9 ilustra la correspondencia de los datos auxiliares que transportan el flujo AC-3 con el cuadro de video capturado.

Page 14: Ejemplo de análisis de flujo binario AC-3€¦ · Ing. J. Daniel Rodríguez Vega Página 3 de 19

Ing. J. Daniel Rodríguez Vega Página 14 de 19 [email protected] http://danielr-be.jimdo.com/

Figura 9. Cuadro de video capturado y los correspondientes datos auxiliares de interés.

Para medir la tasa de repetición de ráfagas se realizó un conteo de paquetes SMPTE ST 291. Esto equivale a contar las tramas AES que transportan los datos de audio AC-3. Se obtuvieron los siguientes resultados:

Número de paquetes correspondientes a la fracción de la secuencia de ráfagas SMPTE ST 337:

53 paquetes

Número de paquetes nulos (relleno):

1143 paquetes

Número de paquetes correspondientes a las dos ráfagas completas SMPTE ST 337:

393 paquetes (7 paquetes correspondientes a la ráfaga #1, más 386 paquetes correspondientes a la ráfaga #2)

Número de paquetes nulos restantes:

12 paquetes

Por lo tanto, la ráfaga completa de datos AC-3 tiene una longitud igual a:

393 tramas AES + 1143 tramas AES = 1536 tramas AES Este resultado se ilustra en la figura 10.

Page 15: Ejemplo de análisis de flujo binario AC-3€¦ · Ing. J. Daniel Rodríguez Vega Página 3 de 19

Ing. J. Daniel Rodríguez Vega Página 15 de 19 [email protected] http://danielr-be.jimdo.com/

Figura 10. Conteo de paquetes de datos SMPTE ST 291.

La tasa de repetición AC-3 cumple con el estándar SMPTE ST 340.

Revisión del bloque de estatus de canal para el flujo binario AC-3 El uso estándar de las 32 ranuras de tiempo de una subtrama AES (documento AES3-2-2009), se modifica cuando se transporta información que no es audio PCM. Cuando tal es el caso, los bytes 0, 1, 2 y 23, en el bloque de estatus de canal, tienen especificaciones obligatorias que se definen en el estándar SMPTE ST 337. Se presenta aquí un resumen de las mencionadas especificaciones, haciendo para ello referencia a la figura 11.

Figura 11. Bytes relevantes del bloque de estatus de canal para el transporte de datos no PCM.

Page 16: Ejemplo de análisis de flujo binario AC-3€¦ · Ing. J. Daniel Rodríguez Vega Página 3 de 19

Ing. J. Daniel Rodríguez Vega Página 16 de 19 [email protected] http://danielr-be.jimdo.com/

byte 0, b0. Debe ajustarse a un valor de “1”, indicándose así el uso profesional del bloque de estatus de canal.

byte 0, b1. Debe ajustarse a un valor de “1”, indicándose así que la palabra que representa la muestra

de audio no contiene información PCM (other).

byte 0, b4b3b2. Deben ajustarse a un valor de “000” (énfasis no indicado). byte 0, b5. Debe indicar el estatus de sincronización de las tramas AES con respecto a la frecuencia

de muestreo de la fuente de audio digital original.

byte 0, b7b6. Deben indicar la frecuencia de transmisión de las tramas AES (frecuencia de muestreo).

byte 1, b3b2b1b0. Deben ajustarse a un valor de “0000” (modo de canales no indicado).

byte 1, b7b6b5b4. Se ajustan en conformidad con el estándar AES3-2-2009 (sin valor específico

obligatorio para el transporte de audio no PCM).

byte 2, b2b1b0. Se ajustan en conformidad con el estándar AES3-2-2009. En el contexto del transporte de audio no PCM, estos bits indican la longitud de la palabra de datos, la cual esta definida por el parámetro data_mode (tabla 5).

byte 2, b5b4b3. Se ajustan en conformidad con el estándar AES3-2-2009, debiendo indicar la

longitud de la palabra de datos no PCM. Dicha longitud esta definida por el parámetro data_mode (tabla 5).

byte 2, b7b6. Deben ajustarse al valor reservado “00” (nivel de referencia no indicado).

byte 23, carácter de revisión de redundancia cíclica. Se ajusta en conformidad con el estándar

AES3-2-2009, indicando un valor CRC válido (diferente de “00000000”) para el bloque de estatus de canal.

Los valores de los bytes 3 a 22 no están definidos para el transporte de datos no PCM. El estándar SMPTE ST 337 recomienda que dichos bytes se ajusten a un valor de “00000000”. Con base en las características conocidas del flujo AC-3 bajo consideración, se pueden predecir los valores que cumplan con el estándar SMPTE ST 337 para los bytes 0, 1 y 2 del bloque de estatus de canal. Tales valores se especifican en la figura 12.

Page 17: Ejemplo de análisis de flujo binario AC-3€¦ · Ing. J. Daniel Rodríguez Vega Página 3 de 19

Ing. J. Daniel Rodríguez Vega Página 17 de 19 [email protected] http://danielr-be.jimdo.com/

Figura 12. Bloque esperado de estatus de canal para el flujo AC-3 bajo consideración.

La figura 13 muestra el bloque real de estatus de canal para la señal de interés.

Figura 13. Bloque real de estatus de canal para el flujo AC-3 bajo consideración.

Observaciones

Los valores de los bytes 0 y 1 están ajustados en conformidad con el estándar SMPTE ST 337.

Los bits 7 y 6 del byte 2 están ajustados en conformidad con el estándar SMPTE ST 337.

Los valores de los bits 5, 4 y 3 del byte 2 indican una longitud de palabra igual a 24 bits, lo cual no corresponde con el valor indicado por el parámetro data_mode. Estrictamente hablando, esto representa una falta de apego al estándar SMPTE ST 337.

Los valores de los bits 2, 1 y 0 del byte 2 indican una longitud máxima de palabra igual a 24 bits,

con los bits auxiliares empleados para representar datos. Esto no corresponde con el valor indicado por el parámetro data_mode, y de nuevo, estrictamente hablando, esto representa una falta de apego al estándar SMPTE ST 337.

Page 18: Ejemplo de análisis de flujo binario AC-3€¦ · Ing. J. Daniel Rodríguez Vega Página 3 de 19

Ing. J. Daniel Rodríguez Vega Página 18 de 19 [email protected] http://danielr-be.jimdo.com/

La figura 14 permite comparar, contra otras señales de televisión, el bloque de estatus de canal para la señal bajo consideración. Las casillas sombreadas muestran valores binarios obligatorios que están claramente definidos por el estándar SMPTE ST 337. En color rojo se muestran aquellos bits que difieren en valor a lo que se espera, o a lo que se indica en el estándar SMPTE ST 337.

Figura 14. Comparación de bloques de estatus de canal para varias señales de televisión HD.

Revisión del estado del bit de validez en las subtramas AES El estándar AES3-2-2009 establece que el bit de validez debe tener un valor igual a “1” cuando la información en el área de la muestra no es adecuada para su conversión digital a analógico (D/A). Tal es el caso para cuando se transporta un flujo binario AC-3. Se verificó el estado del bit de validez en varias subtramas AES. En todos los casos, se observó que el bit esta ajustado correctamente, conforme a lo establecido por el estándar AES3-2-2009.

Page 19: Ejemplo de análisis de flujo binario AC-3€¦ · Ing. J. Daniel Rodríguez Vega Página 3 de 19

Ing. J. Daniel Rodríguez Vega Página 19 de 19 [email protected] http://danielr-be.jimdo.com/

Conclusiones

El flujo AC-3 correspondiente al canal de televisión bajo consideración ES DISTINTO al de los flujos correspondientes a otros canales. La diferencia radica en el hecho de que el flujo del canal de interés contiene la provisión para la inclusión de una estampa de tiempo.

Aún cuando la provisión para la inclusión de la estampa de tiempo esta presente, no se esta

haciendo uso de ella, es decir, finalmente NINGÚN EQUIPO ESTA GENERANDO INFORMACIÓN DE CÓDIGO DE TIEMPO QUE SE ASOCIE AL FLUJO AC-3 DEL CANAL BAJO CONSIDERACIÓN.

El hardware del equipo que genera el flujo AC-3 brinda, por default, la provisión de la estampa de

tiempo; pero el usuario no tiene acceso a la gestión de la misma. Por lo tanto, la inclusión de la estampa de tiempo no es opcional, ya que el equipo que genera el flujo binario no brinda control alguno que permita activar o desactivar dicha estampa.

El análisis de la ráfaga #1 demuestra que el formato de la estampa de tiempo NO CUMPLE con

algunos de los lineamientos del estándar SMPTE ST 339; y en otro rubro está EN CLARA DISCREPANCIA con el estándar SMPTE ST 337.

La inclusión de la estampa de tiempo no esta afectando negativamente la tasa de repetición de las

ráfagas AC-3. El espaciado de la palabra de sincronización Pa es igual a 1536 muestras. Por lo tanto, la tasa de repetición CUMPLE con el estándar SMPTE ST 340.

El análisis del bloque de estatus de canal demuestra que, en algunos rubros, el formato de dicho

bloque NO ESTA CUMPLIENDO con los lineamientos del estándar SMPTE ST 337. LA LONGITUD DE LAS PALABRAS DE DATOS NO ESTA SIENDO CORRECTAMENTE ESPECIFICADA.

En comparación con los bloques de estatus de canal correspondientes a otras señales de televisión,

el estatus de canal para la señal analizada ES DISTINTO, al estar siendo erróneamente especificada la longitud de las palabras de datos. Esto es algo que no esta ni contemplado ni permitido por el estándar SMPTE ST 337.

Por otro lado, dicho estándar sí permite (aunque no recomienda) la no indicación de la longitud de

las palabras de datos (valor “000” para los bits b5b4b3 del byte 2). Este es precisamente el caso que se tiene para los flujos de los otros canales de televisión, en donde no se esta indicando la longitud de las palabras (figura 14).