Dividendo Digital 2.0: TDT sólo en HD

[manuelj_baeza]

Quienes decís eso de los 1200 sin usar estáis equivocados y os diré porqué.

No es nada recomendable exprimir todo el mux, si no que se debe dejar un espacio de "colchón" para cuando alguno de los encoders se pueda disparar un poco por encima de la media. Esto es mucho más importante aún si estamos hablando de muxes que realizan stat-mux, así que no es un espacio que se deje de utilizar por capricho, sino por una recomendación técnica bastante prudente ya que de llenarse el mux se perderían paquetes en algunos de los programas.

[najabi]

Hombre, la finalidad de stat-mux es aprovechar hasta la última gota de bitrate del mux 'robando' la compresibilidad de los demás, si necesita dejar un 'colchón' fijo grande sin usar que no tendría sin stat-mux entonces pierde su sentido. Que sea un máximo de 200kbps, pero no 0.8Mbps como tienen algunos. En teoría no debería necesitar más que un mínimo, si el sistema está bien diseñado con un rango máximo de alocación y compresibilidad (para eso están los búfer, el famoso vbv-bufsize y vbv-maxrate de H264). En cuanto a canales que no aplican bitrate variable, pues puede ser que sean de operadores que no quieran compartir su ancho de banda con otro, por ejemplo DKISS no querrá fluctuaciones de bitrate en su canal que comparte en el mux de RTVE, querrán sus 3.2Mbps fijos.

Sobre aumentar el ancho de banda del mux del actual de 19.8Mbps con 1Mbps más sin perder cobertura como dice el compañero, pues genial, para eso está la tecnología. Eso sí que suma.

Por cierto, no sé a qué esperan para DVB-T2, seremos el primer país con un 4k reescalado público, pero en Europa nos llevan ya la delantera unos cuántos con varios canales. DVB-T2 se aprobó por la ETSI en 2009. 2009 es desde cuando las teles soportan el FullHD que es obligatorio ahora, o sea que operan con un margen de 15 años. No tardarían mucho en incorporar DVB-T2, yo compré en 2015 una LG espléndida de 32'' por 350€ que ya lo tenía, junto a HEVC. Llevan al menos diez años en el mercado. Es más barato comprar un decodificador DVB-T2 por 20€ que instalar amplificadores en una comunidad. La mayoría renovamos la tele principal en 10 años. No podemos ir 15 años detrás de la tecnología. Tenemos que dar saltos obligatorios para ponernos al día. En 2010 fue el apagón analógico y nadie se quejó por comprar un decodificador.

De todas formas cuando metan DVB-T2 no seguiremos con 4 canales por mux, aprovecharán HEVC para meter seis o más en HD o simulcasts con 4k. Seguiran quitando frecuencias a la TDT con el 5G o 6G. No nos van a dar más de un mínimo de calidad para notarse 'lo justo' el cambio. Si pueden meter otro canal no van a darnos calidad exquisita, porque es publicidad o licencias que pierden. Por eso que no me hago ilusiones.

[Alexpotterweb4k]

Pues como dije aunque no sea fácil siempre podrían haberle dado más fuerza y una modulación de 1 o 1,2Mbps más a cada mux y ahí si, repartir 1.100Kbps dsegún necesite cada canal

[Jacintoos]

Voy a contestar a los tres últimos posts en uno solo:

1) No hace falta dejar tanto colchón de padding para hacer stat-mux. De hecho, ese colchón no es para el stat-mux, porque son los encoders los que tienen que trabajar juntos para hacer la multiplexación estadística. El padding es para otras cosas, como las tablas PSI, cambios de modulaciones, etc. En los muxes actuales de la TDT española con dejar un máximo de 500Kbps es más que suficiente. Pero como se ha dicho los hay que están desperdiciando hasta 1,3Mbps.

2) La multiplexación estadística no se basa en "robar" a otros canales. Se fundamenta en entrelazar los frames I que son los que ocupan más, y distribuir el bitrate de los P y B entre los diferentes canales. Los que pensáis con un CBR de 5Mbps es mejor que uno VBR con picos de 8Mbps y media de 3Mbps es que no sabéis de codecs de video. Os animo a mirar los paddings de los fujos de vídeo de los canales CBR, y veréis cuánta morralla hay (nota: no es lo mismo el padding en el PES que el padding del TS).

3) El cambio de modulación en España no es posible, por dos razones: si se reduce el FEC (pasando de 2/3 a 3/4) lo que va a pasar es que en muchos sitios se van a ver muchos errores. Y gente que ahora ve perfectamente la televisión pasará a verla con ruido digital. La segunda razón es que reduciendo el valor de guarda (que aquí es exageradamente grande, porque al principio se utilizaron las SFN), se puede ganar bitrate pero entonces resulta que Cellnex tendría que cambiar un montón de antenas, porque ese valor marca la distancia máxima que puede haber entre dos antenas que emiten la misma señal en la misma frecuencia. El resultado es que ahora no se puede cambiar la configuración técnica de la red de la TDT así que tenemos lo que tenemos (hasta que no pasemos a DVB-T2).

Espero que esto haya aclarado algunos aspectos.

[manuelj_baeza]

Pues díselo a Cellnex, Axion y otros tantos operadores que tienen el empeño de guardar alrededor de 1000 kbps o más de "colchón". Yo creo que en muchos casos no se fían de las configuraciones que tiene porque mezclan encoders de distintas épocas, antiguos, modernos, distintos fabricantes y lo mismo con las cabeceras: algunas antiguas, otras nuevas, etc.

[najabi]

Muy interesante, Jacintoos.

No controlo de multiplexación estadística. Sobre bitrate fijo vs variable en vídeo con códecs como x264, por lo que yo sé en streaming se fija un bitrate medio, y luego internamente el códec emplea bitrate variable o adaptativo haciendo uso del búfer en el decoder para distribuir más o menos bits en función de la compresibilidad o complejidad del vídeo. En blu-rays el búfer es alrededor de un segundo, el estándar es vbv-maxrate=40000 y vbv-bufsize=30000, lo cual da un búfer mínimo de 3/4 o 0.75 segundos y un bitrate máximo transitorio (pico) de 70000 kbps para ése búfer. Por lo que nunca es constante, varía, pero hay un bitrate promedio. No sé si esto es lo que Jacintoos llama el CBR de los canales que emiten con bitrate continuo independiente respecto a VBR del stat-mux. No tiene porqué haber morralla en un stream de estos.

¿Cómo funciona realmente el stat-mux? Cuando digo 'robar' no me refiero a quitar, sino a recibir el bitrate libre que le deja la compresibilidad de otro stream, al final es un búfer que reparte bitrate que sobra entre varios streams. Yo puedo usar un mismo encoder para tres streams con distintos parámetros de compresión, y luego repartir los bits que me sobran entre los 3 streams, dando más cantidad al stream que lo 'necesita' de tal manera que se obtenga una calidad objetiva equivalente. Eso es lo que yo entiendo como stat-mux. Que se junten los cuadros intra de los canales y los P-B por separado en teoría no cambia el funcionamiento del encoder, hay una compresibilidad dada y bits que sobran que hay que repartir y utilizar.

La ventaja del stat-mux sobre el normal es que se reparte el bitrate 'sobrante' instantáneo de varios streams en vez de sólo uno, y el pico es proporcionalmente más alto, pero un mux normal tiene la 'ventaja' de que aunque su búfer es menor emplea sus bits sobrantes en mejorar todos sus cuadros: los más y menos compresibles (de una cuantización predeterminada). Es decir, tiene una calidad en cuadros estáticos más alta.
De todas formas la disponibilidad de búfer depende de que les sobre a los demás en ese instante, si yo tengo una cuantización baja en un instante con mucho detalle , si los otros canales lo tienen también no saco nada. Y al contrario, si cuando a los otros canales les sobra bitrate y a mí también pues me lo como con patatas y no se notará mucho, de ahí lo de 'oportunista' y 'aleatorio': no se garantiza la disponibilidad de bitrate dinámico, sólo el de su propio búfer.

[Jacintoos]

Pues díselo a Cellnex, Axion y otros tantos operadores que tienen el empeño de guardar alrededor de 1000 kbps o más de "colchón".

Curiosamente a Cellnex ya se lo dige cuando era Abertis, pero ellos decían (entonces) que era porque su sistema de distribución tenía que soportar ciertos picos... que venían de cadenas que tenían manga ancha con las pistas de teletexto por el tema de los subtítulos. Vamos que en realidad era porque no querían ajustarlo mejor.

Y en cuanto a lo que comenta Najabi, en compresión de vídeo digital hay que entender en qué contexto se hace: streaming, broadcast, DVD/Bluray, storage, etc. Porque según sea uno u otro, hay que usar PARÁMETROS DIFERENTES para la compresión. Lo explico: Si estás comprimiendo para DVD/Bluray resulta que hay que mantener un bitrate mínimo y no se puede pasar de uno máximo. El máximo es porque el lector no puede dar más, y el mínimo es porque el lector no debe pararse (aunque esto último es con matices). Así que los estándares que fijan cómo deben ser los streams definen esos parámetros. Con encoders como x264 y ffmpeg los valores comunes son precísamente esos, pero resulta que eso no tiene nada que ver con broadcast ni tampoco con streaming. De hecho, si miras los tamaños de los frames I, P y B (y el resto) en PES con los encoders que hablas y con los parámetros que pones, podrás comprobar que en muchas ocasiones hay padding (muchas), y eso es porque cuando no hay movimiento, no hay nada que codificar. Por eso, no hace falta que el bitrate medio en HD con H.264 tenga que ser mucho mayor que 3-3,5Mbps como hacen los broadcasters actualmente. El tema del stat-mux frente al CBR de los canales de televisión (tenemos ambos modos en la TDT española), es que cuando se utiliza CBR resulta que hay escenas (y no pocas) en donde los 4Mbps (aprox) que tienen asignados los que usan vídeo a CBR pues NO SON SUFICIENTES. Cuando eso sucede, los artefactos aparecen. Sin embargo con stat-mux, SIEMPRE que hace falta los picos se pueden alcanzar. Y la calidad máxima está fijada por los picos máximos configurados en el encoder. Que haya que bajar el bitrate de otros canales cuando uno lo necesita, no hace perder (casi) calidad, porque la perdida es mínima. Por eso hay tanta diferencia, por poner un ejemplo, en ver Energy/Boing respecto Mega/Trece en el MPE4. Luego en otro contexto diferente están las codificaciones para streaming que también son diferentes, porque en esos casos el bitrate mínimo desaparece, y el máximo solo está determinado por el buffer de decodificación. Pero lo que sí es determinante en esos casos es el bitrate medio, que dentro del GOP (o del paquete HLS) se necesita que no sobrepase un determinado límite. Como puedes ver en cada caso es diferente, aunque los codecs sean iguales. Así que dejemos ya de hablar de si la TDT española ACTUAL tiene o no tiene suficiente bitrate. Porque en los muxes en donde hay stat-mux se ve perfectamente bien (otra cosa son los audios de algunos operadores, y el padding de sobra que dejan otros). Y lo que habría que hacer es que fuese OBLIGATORIO en todos los muxes (locales y regionales a parte).

[danibcn94]

En unos días cumplirá un mes desde que se hizo la transición a HD... Y las emisiones del canal DKISS continúan viéndose mal.

La señal de vídeo sufre congelaciones de hasta un segundo. Tras observar un rato la transmisión tengo la impresión de que hay un patrón detrás de los parones. Cuando la imagen tiene mucho movimiento hay más probabilidad de que esto suceda que cuando hay pequeñas transiciones, contenidos estáticos... ¿Es posible que el encoder al recibir una señal por encima del bitrate CBR permitido (3.2 MB/s, bastante pobre la verdad) en lugar de pixelar la imagen "decida" saltar unos cuantos frames?

Es bastante lamentable que lleven un mes sin resolver este problema.

En general el MUX RGE2 desde el 14 de febrero es un desastre. Con un canal UHD con un bitrate demasiado bajo, Clan HD usando las migajas, DKISS con congelaciones y para adornar el pastel, 1.8MB/s de emisoras de radio en glorioso MP2 (salvo Radio Clásica).

Ya que se comenta el tema del colchón en cada mux, tiene coherencia que se mantenga un margen de 0.5Mbps para protegerse de picos puntuales de los encoders pero hay MUX con 1.2, 1, 0.9 o 0.5Mbps, no parecen seguir un patrón coherente. En el MPE2 y MPE3 tras apagar los simulcast SD aumentó el colchón en lugar de mantenerse a pesar de haberse reducido la cantidad de señales.

[ingenierito]

El problema de DKISS, a falta de comprobarlo con un analizador, seguramente es que el encoder añade SKIP FRAMES, que es una funcionalidad del H.264 que no existe en MPEG-2. Pero también podría ser un problema diferente que tenga que ver con el multiplexador. Habrá que analizarlo con calma.

En cuanto al espacio de "colchón", como ya se ha dicho no es necesario para la multiplexación, y mucho menos para la compresión. Sino para los streams de subtítulos y teletexto, además de la protección de los flujos en las redes de distribución. Así que se podría perfectamente homogeneizar a 500Kbps en todos los muxes. A ver si Cellnex se pone de una vez a revisar las configuraciones, en vez de lavarse las manos y dejarlo todo como está.

Y otra cosa más respecto al audio: Según la EBU el codec MP2 es uno de los mejores en cuanto a calidad, siempre que el audio no sea multi-canal. Por tanto, siempre que no sea un 5.1 mejor que usen MP2 a 256Kbps que otros codecs más "avanzados" con menos bitrate.

[encintro]

La mala configuración de los MUXES que ha hecho Cellnex es de traca:

- En el caso de CANARIAS sucede alguno muy curioso: El MPE2 (Antena3) en Canarias es CBR (sin stat-mux), y de null padding solo hay unos 800kbps. Mientras que en MPE2 nacional hay stat-mux (con bastante fluctuaciones) y el null padding llega a 1,3mbps. Pero con el MPE4 (Mediaset) es lo contrario: en Canarias sí tiene stat-mux, pero con un padding de 1,2mpbs. Cuando el nacional tiene un padding de 800kbps.

¿Alguien entiende las configuraciones de Cellnex?

[najabi]

Y en cuanto a lo que comenta Najabi, en compresión de vídeo digital hay que entender en qué contexto se hace: streaming, broadcast, DVD/Bluray, storage, etc. Porque según sea uno u otro, hay que usar PARÁMETROS DIFERENTES para la compresión.

A ver, streaming estático (sin HLS ni DASH), DVB-T y blu-ray son casi lo mismo, hay un ancho de banda constante (el del PID asignado dentro del del mux en broadcast y la velocidad máxima de lectura en el caso del blu-ray) y un búfer del códec H264 en la memoria del TV (o del reproductor de blu-ray) dentro del ancho de ese PID. DVB-T y blu-ray usan el mismo contenedor multimedia: MPEG-TS (Transport-Stream). El streaming estático tiene un búfer de red, que funciona de la misma manera.

El stat-mux lo que hace diferente el encoder es codificar los tres streams con un búfer cómún de todo el mux, que hace repartir el ancho momentáneo 'libre' de los tres haciendo un reparto más eficiente. Eso independiente de los parámetros de compresión de cada stream, que pueden ser diferentes para cada uno.

Lo explico: Si estás comprimiendo para DVD/Bluray resulta que hay que mantener un bitrate mínimo y no se puede pasar de uno máximo. El máximo es porque el lector no puede dar más, y el mínimo es porque el lector no debe pararse (aunque esto último es con matices). Así que los estándares que fijan cómo deben ser los streams definen esos parámetros. Con encoders como x264 y ffmpeg los valores comunes son precísamente esos, pero resulta que eso no tiene nada que ver con broadcast ni tampoco con streaming.

Sí tiene que ver blu-ray, broadcast y streaming, lo acabo de explicar. ffmpeg no es un encoder, es una herramienta. El encoder en H264 que utiliza ffmpeg es x264. No hay bitrate mínimo en blu-ray, hay bitrate máximo: 40Mbps, con un búfer de 30Mb. Y eso de que el lector no puede más, el lector tiene una memoria de búfer de 30Mb que le permite ancho de banda variable de acuerdo a la velocidad de lectura, con un máximo instantáneo de vídeo de 70Mbps. En DVB-T es lo mismo: la velocidad de lectura máxima es el ancho del mux o del pid, y el televisor o lector blu-ray que tiene un bufer de lectura conforme a DVB-T, dependiendo del bitrate de ese stream, que no sé a cuánto equivale.

De hecho, si miras los tamaños de los frames I, P y B (y el resto) en PES con los encoders que hablas y con los parámetros que pones, podrás comprobar que en muchas ocasiones hay padding (muchas), y eso es porque cuando no hay movimiento, no hay nada que codificar. Por eso, no hace falta que el bitrate medio en HD con H.264 tenga que ser mucho mayor que 3-3,5Mbps como hacen los broadcasters actualmente. El tema del stat-mux frente al CBR de los canales de televisión (tenemos ambos modos en la TDT española), es que cuando se utiliza CBR resulta que hay escenas (y no pocas) en donde los 4Mbps (aprox) que tienen asignados los que usan vídeo a CBR pues NO SON SUFICIENTES. Cuando eso sucede, los artefactos aparecen. Sin embargo con stat-mux, SIEMPRE que hace falta los picos se pueden alcanzar. Y la calidad máxima está fijada por los picos máximos configurados en el encoder. Que haya que bajar el bitrate de otros canales cuando uno lo necesita, no hace perder (casi) calidad, porque la perdida es mínima. Por eso hay tanta diferencia, por poner un ejemplo, en ver Energy/Boing respecto Mega/Trece en el MPE4. Luego en otro contexto diferente están las codificaciones para streaming que también son diferentes, porque en esos casos el bitrate mínimo desaparece, y el máximo solo está determinado por el buffer de decodificación. Pero lo que sí es determinante en esos casos es el bitrate medio, que dentro del GOP (o del paquete HLS) se necesita que no sobrepase un determinado límite. Como puedes ver en cada caso es diferente, aunque los codecs sean iguales. Así que dejemos ya de hablar de si la TDT española ACTUAL tiene o no tiene suficiente bitrate. Porque en los muxes en donde hay stat-mux se ve perfectamente bien (otra cosa son los audios de algunos operadores, y el padding de sobra que dejan otros). Y lo que habría que hacer es que fuese OBLIGATORIO en todos los muxes (locales y regionales a parte).

A ver, el stat-mux no hace milagros, tiene un búfer en cada momento (mayor o menor) para repartir entre los streams, dependiendo de la calidad objetiva en ese momento, es decir: el cuantizador. (la complejidad del fotograma). No tiene nada que ver el GOP de H264 con HLS, son cosas distintas. Tampoco tiene que ver exactamete los tamaños de I,P,B con el bitrate medio asignado: Estás mezclando cosas: cada stream tiene un bitrate medio asignado, pero dependiendo de la complejidad del fotograma los tamaños I,P, y B variarán, sea stat-mux o no.
Que un canal en un mux normal tenga una asignación constante de ancho de banda no significa que no tenga un búfer y que el bitrate instantaneo sea variable (no es CBR exactamente, eso es en audio), lo tiene y en cambio de escena hace uso de ése bufer. La diferencia con stat-mux es que ese búfer se comparte entre los streams (en vez de uno sólo) y se reparte en cada instante de la manera más eficiente dando más al que tenga la cuantización más baja, y con un rango de pico más alto (pero limitado) para uno sólo de los streams (los tres no pueden tener el mismo pico a la vez) frente al caso de un mux normal.

Sobre los colchones del mux, me parece excesivo que tengan que reservar 500kbs, eso está mal diseñado. El vídeo y el audio no requieren de colchones adicionales, ya tienen su propio búfer y asignación. Igual es lo que dice el compañero de subtítulos o teletexto, pero creo que eso debería estar asignado dentro de cada stream, como los audios y el vídeo, y no fuera de él como espacio libre en el mux. Tiene pinta de que eso está mal diseñado. ¿Quién usa el teletexto en 40 millones de habitantes? Madre mía, eso es caduco hoy día con HbbTV e internet, es un ancho de banda inútil. Y los subtítulos, no sé que protocolo usan, debería ser texto en claro con formato a un bitrate muy bajo, no bitmaps como el dvd y blu-ray: ¿crece y mengua sin control hasta 500kbps? ¿"Protección de flujos de las redes de distribución"? Jarr me lo expliqueen En 500kbps se metía una película en divx hace veinte años, es un 8% del vídeo de un canal.

Y lo de los mux de Canarias, pues qué te voy a decir, van una hora menos y a su bola , pero no deja de ser curioso. Igual es por la orografía volcánica y protección de rebote de las ondas

[najabi]

Y otra cosa más respecto al audio: Según la EBU el codec MP2 es uno de los mejores en cuanto a calidad, siempre que el audio no sea multi-canal. Por tanto, siempre que no sea un 5.1 mejor que usen MP2 a 256Kbps que otros codecs más "avanzados" con menos bitrate.

Eh? MP2 es un códec primitivo de 1991, anterior al MP3. Es computacionalmente más sencillo y menos eficiente que todos los demás posteriores. No tiene nada que hacer con el resto de códecs de la tdt, y si está ahí es un misterio y una pérdida de calidad para todos los canales de la radio que lo utilizan. Probablemente DVB-T lo estableció como codec en su inicio para radio y vídeo en SD (MPEG-2/MP2 como ha tenido el SD hasta febrero de 2024), pero es que AAC (supongo) y EAC-3 se utilizan en HD en DVB-T desde que Telecinco comenzó a emitir en 2010. Hoy que se ha eliminado el SD el MP2 está de más, y deberían sustituir todos los streams de audio de radio en MP2 por AAC o E-AC3. RadioClásicaHQ lleva un montón de años emitiendo en simulcast en EAC-3 (DD+2.0) a 256kbps y MP2 a 160kbps. ¿Qué pinta ése simulcast hoy?. Radio3HQ sigue emitiendo (parece) en MP2 aunque a 256, pero se sigue oyendo peor que el EAC-3.

¿A qué esperan para emilinar el MP2 de la radio en tdt? El DVD, que es un año anterior a DVB-T, aunque es compatible con MP2, el audio es AC-3 (Dolby Digital) por defecto desde el principio, jamás he visto ningún audio de DVD en MP2. Excepto Radio3HQ y RadioClásicaHQ la calidad de sonido de las emisoras de música es deficiente, exceptuando alguna de Los40. Hay compresión de onda a saco, están maximizadas y no tienen casi agudos. Son para tirar por el desague, prefiero la FM del coche. Todo esto aparte de la música que ponen, que es otro cantar. Sin embargo, el sonido de los canales generalistas en SD en MP2 ha sido medio decente en general, han estado optimizados, aunque les faltaba chispa en agudos. Paramount se oía fatal. En los HD la calidad de sonido ha sido buena, EAC-3 o AAC a partir de 192kbps en estéreo está bastante bien, nada que reprochar.

[IncognitoTelevision]

El tema de los paquetes nulos. Hay dos maneras de hacer stat-mux en redes DVB o ATSC, aunque realmente esto de los paquetes nulos también aplica a CBR.
Basicamente, en ambos métodos (y en CBR) es muy muy raro que se dejen menos de 300 kbps de null packets. Y cuando son tan pocos, es porque son multiplexados al límite.

Metodo Estándar: El que se usa cuasi-universalmente (la de meter mas canales de los necesarios y que los encoders hagan la magia del regateo aprovechando la disparidad de demanda). A espectro más limitado, menos paquetes nulos. Este es también el caso de la TDT española.

Francia DVB-T (Entre 600 y 2000 kbps):


Alemania DVB-T2 (Entre 500 y 1000 kbps):


Polonia DVB-C. En cable van sobrados, es fácil ver en DigitalBitRate hasta 8 Mbps de null packets, para que te de un parraque por ineficiencia:


Chequia-Eslovaquia & Hungría DVB-S2 (Thor). Incluso en TPs portugueses de 30W con trescientos canales, es dificil ver menos de 800 kbps de nulls:


Estados Unidos ATSC (NBC-Telemundo NY, en VBR). Pocas cosas con tanto overbooking hay en el mundo DTT como un mux ATSC en una gran ciudad estadounidense en transición a ATSC 3.0. Pues bien, ahí tienen su parcelita vacía.



Método BBC
Con la llegada de Freeview y Freesat HD, el departamento de investigación e innovación de la BBC consideró que la mejor manera de garantizar la calidad de los canales en un mux, es trabajando como si fueran streams de video con bitrate estático. Se escoge un bitrate adecuado objetivo y, a partir de ahí, el encoder tiene una indecente cantidad de espacio disponible para alocar a un canal emitiendo escenas exigentes, sin con ello comprometer al resto de servicios. Es tan minoritario que, Sky, que se encarga oficiosamente (oficialmente BBC Distribution), de manejar los transponders de toda la huella, no lo utiliza en su propia plataforma. Solamente en donde hay servicios BBC.




Y para cerrar:
Caso CBR: Canadá & Corea del Sur
En Canadá, a diferencia de sus vecinas de continente, México y Estados Unidos, la transición digital a ATSC no trajo nuevos canales gratuitos. La televisión digital terrestre se ha enfocado, exclusivamente en mejora de la calidad de imagen (aunque por motivos legislativos, más que por amor a la técnica). Así que los canadienses disfrutan de canales MPEG 2 HD de 15-18 Mbps. Pues ni por esas, ven conveniente tener un buen colchón de null pids y null packets.



Conclusión:
Será espacio desaprovechado, pero los broadcasters de medio planeta no pueden estar equivocados. Y seguramente en ISDB también se tengan en sus 13 capas paquetes nulos, porque es algo universal.

Como dice el compañero @manuelj_baeza , no es un capricho. Ni técnicxs ni ingenierxs saben cuando un PID se les va a ir a la Luna por defecto de producción, transmisión o encodificación. Antes de nada, lo importante es cumplir con los mínimos de Periods of Disruptions (que suelen ser altísimos en DTT) y con mantener la estructura lo menos mantenible posible.

Y claro, estamos en el siglo XXI. Un equipo en remoto de 10 personas se puede encargar de una red de un país como el nuestro o de una huella satelital entera. Ya no viven los ingenieros en los repetidores ni las salas de control de satélite DTH parecen las de la NASA. Si un mux empieza a tener problemas por este motivo, pueden pasar horas hasta que sepan de donde y quien tiene el problema. Y normalmente será cuando el usuario final lo sienta (caídas, datos corruptos, etc.). Y si el cliente se entera, las clausulas de pliegos, contratos o leyes van a darle unos cuantos dolores de cabeza (y multas) a los Cellnex, Télédiffusion de France, Sky, o cadena norteamericana de turno. Mejor no arriesgar.

[Alexpotterweb4k]

Viendo lo de UK me parece una burrada, teniendo 40Mbps y solo para que los canales tengan 3 -4Mbps, si aquí tuviésemos 20 o 21,90Mbps se iban a enterar la calidad que ofrece no desaprovechar tanto los Mbps, que 9,9Mbps es demasiado, aunque si lo necesitan y así quedan a la par o peor que nuestra TDT, pues vale.

[Jacintoos]

Leo por aquí comentarios, que desde luego son bien intencionados, pero que desgraciadamente se percibe (o eso pienso) que no habéis trabajado en broadcasting. Y siento deciros que algunas de las cosas que dais por hechas a nivel técnico no lo son. Posiblemente solo sea porque no os las han explicado, y lo habéis aprendido por vuestra propia experiencia y/o aprendizaje autodidacta. Pero yo no voy a ser quien vaya de listo y tenga que decir cómo son las cosas. Esto es un foro, y aquí se pueden expresar opiniones. ¡Faltaría más!

Ahora bien, por favor, que quede claro que elegir un valor de colchón (y no lo llamo aquí valor de guarda, que es lo que realmente es, para no confundirlo con el valor de guarda de la codificación de la señal) para el padding de un MPTS no deja de ser un valor técnico que se elige. No es por tanto algo que quede fijo. Y que hay varias razones para elegir un valor que no sea muy pequeño. Y también que cuando se utiliza stat-mux ese valor puede (o no puede) ir variando. Pero que la experiencia y las recomendaciones de la EBU indican que para un MPTS de 20mbps como los que usamos aquí en la TDT es suficiente con unos 500kbps. Y efectivamente tenemos muxes bastante bien ajustados. Por poner algunos ejemplos: el MPE-4 tiene justo 500kbps de padding. El RGE-1 en Cataluña tiene 600kbps. El mux de TV3 tiene 650kbps. Y el de Sabadell (TL07B) 450kbps. Que por cierto, son los valores medios, porque logicamente fluctúan debido a las tablas PSI/SI, los subtítulos y otras causas.

En consecuencia, cuando se dice que Cellnex puede ajustar mejor los padding de muxes como el MPE-2 con 1,2Mbps sin uso, pues es que puede hacerlo sin problema alguno.