El Gobierno empieza la migración de la TDT a DVB-T2 (SÓLO comentar cuestiones TÉCNICAS)

[Invitado]

Viendo mejor el panorama ojalá rasquen hasta 33,50Mbps y que en el RGE2 metan audio 250kbps en cada canal y en la fase 2 los canales HD vayan a 6,1Mbps de bitrate fijo con stat mux hasta 6,8Mbps y 198kbps de audio, mejoraría calidad de forma muy general , aunque sea pequeñas mejoras en x cosas y con eso perfecto para tener un buen audio etc en todo.

[najabi]

Bueno: es que la compresión "buena" de verdad NO sería ABR (Average Bit Rate; se define un bitrate promedio a alcanzar), sino VBR (Variable Bit Rate; se define una calidad promedio a alcanzar, sin concer el bitrate concreto necesario), que es la que yo usaba al codificar audio.
Metía VBR Q 127, que es la calidad más alta para AAC, y, en general, con un bitrate promedio ridículo tenía un audio indistinguible del original (estoy hablando de películas).

Pienso que el bitrate variable en audio para la tdt se establece con parámetros de mínimo, medio y máximo. No es VBR libre ni ABR como cuando comprimes para archivo. Porque siempre son los mismos valores: 64 - 72 - 80.

No hay "constant ratefactor" en audio como lo hay en vídeo, aunque un VBR puro sería lo más parecido. Un VBR puro no tiene limite instantáneo ni mínimo ni máximo, apunta a un valor medio en el tiempo. En un mux de tdt tienes que acotar estos valores para ser predecible y no desbordar el mux.

Si tienes el mux bien diseñado, pienso que puedes calcular el colchón que necesitas con precisión: si usas audio variable calculas el máximo y por encima sería el margen. El stat-mux de video está definido en su contenedor, no varía. Si se reserva un colchón tan alto debe ser por otros factores: los descriptores de pista o algo así. Pero no entiendo cómo hay colchones de 1 Mbps: de qué sirve apurar la capacidad de un mux si luego voy a dejar tanto bitrate libre.

¿Alguno de los técnicos nos explica por qué MPE1 de Madrid con 4 canales a bitrate constante de audio y vídeo, excepto la audiodescripcion de Paramount Network que va a 64 -72 - 80 kbps variable, tiene un colchón PID null de 1 Mbps? ¿Por qué desperdicia 1 Mbps? Qué componente puede oscilar tantísimo como para requerir 1 Mbps libre? Hay unas TABLES ECM/EMM a 0.31 Mbps que no están incluidas en el Pid Null ni en el resto.


¿Por qué el MPE3 de Madrid (Mediaset) que tiene 4 canales en stat-mux con todos los audios a bitrate constante, y el contenedor de stat-mux también a bitrate constante, necesita un colchón PID null de 0.9 Mbps? ¿Por qué no aprovecha ese Mbps y lo distribuye en el vídeo? Los bits de descripción de canal no pueden absorber 1 Mbps. Las TABLES ECM/EMM son 0.16 Mbps, y el Pid null 0.86 Mbps (0.9).

[Invitado]

Pues no se lo que se necesite de colchón con dvb-t2, pero en vez de mínimo y el máximo de 1Mbps, lo suyo sería un término medio de unos 680kbps de colchón fijo en cada mux. Eso sí se puede hacer y si no, lo que se pueda y se deba.

[manuelj_baeza]

Para saber porqué esta ese colchón hay que saber cómo funciona digital bitrate, que es la fuente del gráfico. Son trozos del mux de varios que posteriormente, tras su análisis, se cuelgan con su gráfica. En esos trozos no se ve lo que ocurre las 24h minuto a minuto, sino solo los trozos recogidos.

El bloque de datos ya de por si es dinámico y tiene unos mínimos y máximos, aunque estos máximos no son los más "peligrosos", pero sí que los encoders, la gran mayoría tienen un margen de error que aumenta notablemente en el caso del statmux.

Es esto último lo que hace que sea necesario dejar algo más de colchón y por eso, en otros mux sin statmux está más apurada la tasa binaria disponible.

Por unos cuantos kbps no vale la pena jugársela y que se pierdan paquetes porque el mux se desborde.

[najabi]

Bueno, no parece que todos los stat-mux tengan más colchón, ni que los normales tengan menos: MPE4 con 2 canales en stat-mux tiene 0.6 Mbps y MPE1 normal tiene 1 Mbps. ¿Cuál es el sentido de ese megabit por segundo vacío con todo constante? ¿Cuando dices que el bloque de datos ya es dinámico de por sí a qué te refieres? Las tablas ECM/EMM van de 0.17 en MPE2 a 0.45 Mbps en RGE2. ¿El tamaño de estos datos no está acotado?

En el lado opuesto, tenemos MPE2 stat-mux con 1.23 Mbps de colchón (un 6.2% del mux) mientras que MPE5 normal tiene 0.40 Mbps. ¿De qué nos sirve el stat-mux si perdemos 0.80 Mbps de colchón de más respecto a constante? Es posible que digitalbitrate recoja muestras de momentos regulares, pero si no caza ninguno de los picos en las 15 muestras que toma por gráfico, y en cada muestra se captan unas cuantas líneas de gráfico con oscilaciones...

¿Por qué el contenedor de vídeo del stat-mux es siempre constante? Sólo oscilan los canales individuales, la suma es siempre constante, por lo que el encoder de vídeo está siempre acotado. No parece que el encoder tenga un "margen de error". Un encoder se parametriza por completo. Sólo si se diseña con un margen de crecida, puede tener sentido el colchón que dejes. Eso de dejar "por si acaso" no parece muy técnico. O es constante o no lo es. Pero es que sinceramente no veo que sea por esa razón porque hay muxes normales con 1 Mbps de colchón y ahí todo es constante por lo que el encoder se descarta.

[manuelj_baeza]

Los encoders no son exactos, cada marca y cada modelo incluso de la misma marca generan variaciones, aunque se les ponga la misma cantidad de tasa binaria para vídeo y para audio. En el MPE5 tienes el ejemplo de RMTV que quizá sea el más destacable.

[najabi]

RM en MPE5 es plano como una tabla a 4.4 Mbps, al igual que BEMAD y A3SERIES. El único que oscila una miga es TEN que indica 3.8 min 3.8 med y 3.9 max. Debe ser cosa de su encoder concreto, pues los 4 canales son de grupos distintos. Los audios de los cuatro canales también oscilan un pelín, a pesar de tener todos el bitrate constante. Esto pasa en todos los muxes, por ser DATA+AUDIOS. Ahí hay algo en DATA que oscila (¿las tablas?). Pero todos juntos apenas comen nada del Pid null, que es de 0.4 Mbps. Podría pasar con menos.

El MPE3 de Mediaset tiene el stat-mux como una tabla de liso, sólo los audios oscilan un pelo, y tiene 0.9 mbps de colchón. Se puede reducir seguro. Son los 4 canales del mismo encoder.

Con el MPE2 de A3Media lo mismo: el stat-mux es plano, sólo los audios oscilan un poco más que en MPE3, y sólo come una pequeña parte del colchón de 1.2 Mbps de media. Está bien que los muxes son suyos y se lo distribuyen como quieren, pero que lo optimicen, leñe.

En RGE1 el stat-mux es plano, sólo los datas+audios que son fijos oscilan un poco más. Pero le sobra espacio del Pid null de 0.8 Mbps, podría con la mitad.

En los muxes de otros países también hay Pid null, pero en general son más pequeños (0.3 Mbps). Y los encoders oscilan poco o nada, tanto normal como stat-mux. No justifica 1 Mbps. Aunque hay por ahí algún stat-mux francés que se come a ratos bloques de un colchón de 2.30 Mbps. Pero eso es que no está bien diseñado. Tiene un canal fantasma que aparece y desaparece.

[manuelj_baeza]

Oscilan muchas cosas. Datos HBBTV, descriptores de lanzaderas de las apps, número de apps simultáneas, teletexto, datos de subtitulado que no está siempre funcionando, etc. Y luego los propios descriptores con información interna de los codecs de vídeo y audio (no los del mux) del propio encoder, que puedes encontrarte con que un audio de 192 kbps esté consumiendo 224 kbps y cosas similares.

TEN tiene menos tasa binaria, igual que DKiss y otros, porque se le resta a la tasa de vídeo la que usan para las radios que emiten junto a su servicio.

[najabi]

Los DATOS+AUDIO oscilan, pero oscilan poco como puede apreciarse en todas las gráficas. El Pid Null se puede bajar hasta 0.3-0.4 Mbps en todos los muxes. Especialmente en aquellos que gastan 1 Mbps. Insisto tanto porque como se ha hablado tanto de ganar espacio en el nuevo mux DVB-T2, que si intervalo de guardia etc, que no nos damos cuenta que se puede ganar más de medio Mbps acotando bien el colchón.

Los encoders de video son totalmente planos, tanto en mux normales como en stat-mux, excepto el de TEN que oscila una miga, 0.1 Mbps. Los audios los doy por sentado que no oscilan. Los datos oscilan como digo poco, excepto el RGE1 en concreto que es un poco más, pero con 0.3-0.4 Mbps de colchón lo absorbe y le sobra. En los muxes extranjeros hay varios a 0.3-0.4 Mbps también.

Nuestro mux con colchón más pequeño es precisamente MPE5, el de TEN, que es 0.4 Mbps, y le sobra aún. Pero es que en RGE2, MPE1 y MPE2 es de 1 Mbps. Y el de mi autonómico de EITB es de 1.3 Mbps. En todos estos la oscilación de datos es muy poquita y sobra. Y todos tienen Hbbtv, teletexto, etc. Hbbtv serán enlaces de hipertexto a internet. Flipo en pleno siglo XXI con los móviles cómo siguen usando el teletexto, 150-189 kbps de media, que no lo ve nadie. Igual alguno el décimo de lotería.. Lo de descriptor interno del códec de audio (metadatos?) de 192 kbps que ocupa 224 no puede ser, es mucho margen, debería corregirse. El subtítulado veo que oscila bastante, entre 20-40 kbps de media y 70-99 kbps de máximo. En cualquier caso es acotable. Y el Pid-null no apura tampoco el tamaño total del mux, hay un hueco entre ellos. El límite superior del pid-null oscila un pixel a veces.

[manuelj_baeza]

Los encoders pueden variar unos 100 kbps por cosas muy puntuales que, como expliqué, no tienen porqué quedar siempre registradas en las gráficas de digital bitrate.

Si en el mux tienes varias codificaciones de vídeo (vamos por 4 camino de 5), más varias con audios, más la de datos que también oscila, más casos como el RGE1 con la suma de 2 multiplexados (cada uno con su colchón) ahí lo tienes. Nadie en Cellnex ni en las teles se la va a jugar a que se produzcan microcortes en la señal o pérdida de paquetes porque el mux se desborde. Prefieren que haya una calidad un poco más ligera.

[Teletexto]

Lo que muestra la gráfica en digitalbitrate es una media de los bitrates en un intervalo de varios segundos. Dentro de este intervalo puede haber (y los hay) picos más altos. Pero no se ven porque se ve el valor mediano. Además los datos se mandan en paquetes de 188 bytes. No es posible tener bitrates aleatorios. Aunque solo se necesita emitir un bit, hay que mandar 188 bytes. Y en este tiempo no se puede mandar ningún otro PID.

Muchos paquetes con Null PID existen porque hay varios datos que se emiten en VBR. Mientras su bitrate es más bajo, se rellena con el Null PID.

No se puede hacer statmux ni con los subtítulos ni con audio ni con otros datos. En comparación con el vídeo la codificación de audio no tarda nada y se manda en paquetes de más o menos 20 ms. Otra vez el mínimo son 188 bytes. No sirve de nada disminuir unos bytes en un intervalo de 20 ms. En el vídeo el retardo de codificar puede ser de varios segundos. Es el tiempo en el que los codificadores pueden comunicarse entre ellos para compartir el bitrate. En el audio no existe este retardo en el que se podría compartir el bitrate.

Lo mismo con los subtítulos. Cuando hay que mostrar una frase, se emite una ráfaga de paquetes. Después ya no se emite nada hasta la siguiente frase. No puedes decir que vas a retrasar un subtítulo porque a la vez hay que emitir otro en otro programa.

Todavía hay bastantes usuarios de teletexto. Los de 60 años para arriba no se llevan muy bien con los móviles, tabletas, ordenadores,... Además, el teletexto es el único medio de transporte universal para los subtítulos. Muchos operadores de IPTV y OTT como Movistar utilizan los subtítulos de teletexto como la fuente para generar los subtítulos IPTV/OTT.

Si hay tantos paquetes Null PID, es porque lo probaron y teniendo menos, se estaban perdiendo los paquetes útiles en emisión. No están allí porque les da la gana. Si te descargas el flujo, puedes calcular los picos del bitrate y verás que son mucho más altos de lo que se ve en la media de varios segundos. Al multiplexor no le puedes decir que haga esta media en la emisión retardando la emisión de varios paquetes cuando hay un pico de otros. Si un paquete llega tarde, tienes un microcorte de audio o parecido.

¿Por qué hay menos paquetes Null PID en algunos MUX? Es porque emiten el relleno en los PIDs útiles en vez de emitir Null PID. Por ejemplo el PID de subtítulos va todo el tiempo en CBR con sus 128 kbps emitiendo un relleno en el PID de subtítulos entre uno y otro subtítulo. En Francia normalmente lo tienen así y algún programa en España también. El "colchón" es el mismo, solo que no va dentro de Null PID y por eso crees que es más pequeño.

Lo que se refiere al AAC. La mayoría de receptores requiere que el audio principal y el de audiodescripción tienen que ser de la misma familia para poder mezclarlos. Los dos AAC o los dos Dolby/AC3/AC4. VBR en el audio no da ventajas. Aún así todavía hay algo de margen de mejora eligiendo una codificación del audio adecuada.

[manuelj_baeza]

Muy bien detallada la explicación, @Teletexto.

No conocía eso de que no se podía usar distintos codecs en el caso de señal principal y audiodescripción.

[najabi]

Yo también agradezco a @Teletexto la información pormenorizada. Aunque no dudo de sus palabras , tengo las siguientes alegaciones:

- El que haya picos momentáneos de bitrate tan altos en un mux relativos al encoder de vídeo (es el único que puede oscilar tanto) sólo significa que éste está mal diseñado. Lo del relleno de paquetes Null PID se asocia a los VBR (un audio de audiodescripción, los subtítulos y teletexto) y esos son oscilaciones de 200 kbps máximo. Eso no desborda un mux de 0.4 Mbps de colchón.

-Además, si hay otros muxes con poco Pidnull como MPE5 significa que los encoders de video funcionan bien y no producen picos tan altos. Aunque los VBR se rellenaran con Null Pid no subirían de 0.4 a 1.2 Mbps.

- Hoy día no se puede asurmir que un encoder de vídeo se desmadre con el bitrate. x264 tiene parámetros para acotar los picos, los más famosos: vbv-max y vbv-bufsize. Con esta combinación es imposible que el encoder produzca picos más altos que la suma de ambos, yo mismo he analizado gráficas de mis encodes viendo los picos momentáneos absolutos.

- 1Mbps es casi un tercio del precio de una licencia de un canal. El ancho de banda de un canal es oro. No tiene sentido que por culpa de un encoder se pierda espacio últil.

-El teletexto es una pérdida de bitrate. Nadie lo usa. Los mayores que no se entienden con la tecnología no se meten con las teclas del teletexto y los colorines que ya no están en los mandos, te lo aseguro. Yo tuve 4 abuelos y jamás les vi con el teletexto. Es una rémora del analógico. Yo no sé qué formato tienen los subtítulos, si usan los del teletexto pero existen otros universales como el texto en claro .srt que no ocupan nada.

- El gráfico de digitalbitrate tiene unos cuantos pixeles por muestra, yo cuento al menos 26. No sé de cuántos segundos es la muestra pero da una buena idea de la oscilación en tiempo real del mux. No serán instantáneas pero insisto: un encoder de vídeo no puede desmadrarse.

[Teletexto]

Simplemente hay que contar:
RGE1: La 1 y La 2 tienen cada una dos PIDs con subtítulos. tdp y 24h cada una tiene un PID. En total 6 PIDs. Cada uno puede subir hasta 128 kbps. La suma son casi 0,8 Mbps. Normalmente todos están en cero, utilizando el Null PID estos 0,8 Mbps. Cada vez que hay que mostrar o borrar un subtítulo sube uno de ellos a 128 kbps.

Detrás de los subtítulos hay muchas organizaciones de gente que los necesita, midiendo y protocolizando durante todo el tiempo la calidad y el retardo. Si les bajas el bitrate a uno de ellos a menos de 128 o no dejas que todos a la vez suban a 128 si en todos aparece el subtítulo casi a la vez, en la suma a 0,8 Mbps, se retrasarán los subtítulos. Si es RTVE se debatirá el problema en las Cortes y al Presidente no le gusta esto. Si es una tele privada caerá la multa de la CNMC. Tampoco quieren esto.

Y si no te gusta la forma de mandar los subtítulos y quieres utilizar otra como .srt, ya estará el abogado de un fabricante de las teles tocando a tu puerta porque no estás utilizando una norma de ETSI prevista para las emisiones TDT.

[najabi]

La ETSI tiene otro estándar de subtítulos mejor que el antiguo de bitmap, el TTML (EN 303 560), aprobado por DVB en 2017 y se usa en plataformas IP y es estándar de EBU-TT-D usado en DVB-DASH y HbbTV.
No tiene mucho sentido andar con bitmaps cuando ocupan tanto ancho de banda, más aún para UHD. No puede ser que unos subtítulos en un mux lleguen a 0.8 Mbps. Supongo que los de bitmap son los utilizados hoy (EN 300 743). Supongo también que la mayoría de las teles son compatibles con TTML ya por lo que podría migrarse en breve.

Mencionabas antes que el teletexto tiene sus propios subtítulos, y que es un estandar universal hoy que tomaba Movistar. Me suena que en el analógico había subtítulos de teletexto. ¿Hoy también se usan los del teletexto? ¿O son sólo los de bitmap de DVB EN 300 743?

En cualquier caso, el teletexto está de más y los subtítulos de bitmap son tremendamente ineficientes. 128 kbps para "borrar" un subtítulo en pantalla es una broma. En ese tamaño ocupas un segundo de audio. Ya hemos encontrado los culpables del colchón:

RGE1: 4 teletextos: 0.8 Mbps que no utiliza nadie, los gastan todos los canales y podrían ir a vídeo. Subtítulos de bitmap: Puede usar hasta 0.768 Mbps de pico, en una muestra cualquiera usa 0.360 de pico. Luego entonces el colchón real necesario es 0.768 - 0.360 = 0.408. RGE tiene uno de 0.5 Mbps, luego está bien calculado: puede absorber los subtítulos. El teletexto es casi constante, oscila unos pocos bits. Tenemos dos sistemas de subtítulos duplicados: el del teletexto y los de bitmap de DVB, redundantes. Con un sistema valdría. Si RGE1 logra un NullPid de 0.5 Mbps, ¿no podrían MPE2 y MPE3 usar esa cantidad? MPE2 está usando ahora 0.369 de pico de subtítulos en los cuatro canales, su pico absoluto es 128 x 4 = 0.512 Mbps, luego sólo necesita 0.512 - 0.369 = 0.143 Mbps de colchón. Sin embargo utiliza 1.2 Mbps. ¿Quién lo genera o para qué se reserva? El contenedor de stat-mux es plano..

Conclusión: Sin teletextos ni subtítulos de bitmap se ahorraría 1.2 Mbps de media por mux. Ajustando el colchón a 0.5 Mbps desde 1.1 Mbps se podría destinar en total 1.8 Mbps para vídeo (si es realmente factible). Convirtiendo los subtitulos a TTML se ahorraría al menos el 90% de lo que gastan ahora. Quitando los audios secundarios de Tdp y 24h: 186 kbps. Todo esto se podría aplicar a la fase 1 para alojar 5 canales. La duda que tengo es la compatibilidad de las teles antiguas con TTML. Si la norma es de 2017 supongo que lo reservarían para fase 2.