Fraunhofer presenta su nuevo estándar de compresión de vídeo, H266 [ENG]

Tras dedicar varios años a su investigación y normalización, Fraunhofer HHI (junto con socios de la industria como Apple, Ericsson, Intel, Huawei, Microsoft, Qualcomm y Sony) está celebrando el lanzamiento y la adopción oficial del nuevo estándar mundial de codificación de vídeo H.266/Versatile Video Coding (VVC). Este nuevo estándar ofrece una compresión mejorada, que reduce los bits requeridos en un 50% en relación al anterior H265 sin reducir la calidad de la imagen.

[#1 Artok]

El doble de porno en el mismo espacio

[#2 Cehona]

#1 8K para que luego te pixelen los japoneses.

[#3 Peachembela]

deberían colocarles otros nombres, esa nomenclatura lleva a confundir.

[#4 vacuonauta]

#3 confunde, sí, pero mejor eso que ir de ultracompression a ultracompression supra y de ahí a ultracompression supra top, etc

[#5 txirrindulari]

#3 ¿qué te confunde?¿la H? h264, h265, h266

[#6 Sadalsuud]

#2 Solo por eso Lucifer, en su sabiduría, tiene un lugar especial en el infierno para todos esos hipócritas de ojos rasgados que sacaron adelante la ley que obligaba a censurar los genitales, junto con los que codificaban el canal plus los viernes por la noche, y otro para la... bueno, pues eso, lo dejo así que no quiero ganarme un calzador...

[#7 Desactivado]

#1 ¿Aún almacenas porno? Bienvenido a la época del streaming. Xvideos, Pornhub hay cantidad indigente de material porno sin almacenar nada.

[#8 Desactivado]

#2 La codificación del C+ del siglo XXI.

[#9 Desactivado]

#1 Y una CPU así de grande para poder verlo.

[#10 Enfin...]

#3 Hay otra nomenclatura:
H264 = AVC (Advanced Video Coding)
H265 = HEVC (High Efficiency Video Coding)
H266 = VVC (Versatile Video Coding)

[#11 kNo]

Ya nos van a vender nuevas necesidades:
The new chips required for the use of H.266/VVC, such as those in mobile devices, are currently being designed

[#12 ccguy]

#7 el porno es de las cosas que o guardas o puedes no volver a localizar.

[#13 Razhan]

Me parece absolutamente increíble como siguen logrando exprimir aún más los algoritmos de compresión. Donde está el límite?

[#14 Catapulta]

El flautista retorna!

[#15 mmvv]

#10 en realidad, es la parte simple...

Los estándares de vídeo de MPEG (que forma parte de ISO) se desarrollan conjuntamente con ITU-T (otra organización de estándares). ITU-T H.266 es el nombre del estándar (oficialmente “recomendación”) en ITU. El nombre “oficial” en MPEG es ISO/IEC 23090-3 (MPEG I parte 3).

[#16 Akrai]

#11 no sé si es que esperabas que un nuevo sistema de codificación y descodificación se pudiera hacer en hardware no diseñado para ello

[#17 ailian]

#16 Se puede hacer por software.

[#18 Desactivado]

Gran noticia, para el mundo del videostreaming es muy necesario mejorar la reducción de datos emitidos. Hay muchas partes del mundo con limitada conectividad a la que solo se puede llegar con satélites y en el que la transmisión de video es casi imposible.

Lo que no dice es la capacidad de cómputo requerida, y la comparativa con VP9. H265 ya pierde con VP9, ¿es H266 superior?

Sobre todo en la necesidad de hardware y el consumo de batería. H264 requiere la mitad de potencia que VP8 pero a su vez comprime significativamente menos. ¿H265 consigue estos ratios de compresión agotando la batería de los móviles y sobrecalentándolos?

De poco sirve mejorar H265 si es computacionalmente tan caro que solo sirve para comprimir archivos almacenables. El reto está en la streaming.

[#19 torkato]

#7 El streaming es muy bonito hasta que deja de estar lo que quieres. Mejor invertir en discos duros.

[#20 torkato]

#17 por software se puede hacer, pero va fatal.

[#21 Desactivado]

#16 Codificar y decodificar no debería necesitar hardware específico. VP8 no lo necesita, Apple acabó aceptándolo en su webview para iOS tras varios años resistiéndose a deja de imponer H264/h265 y no necesitó hardware nuevo.

https://www.reddit.com/r/apple/comments/b0nwps/safari_to_support_vp8_video_codec_from_v121/

[#22 BM75]

#11 No pasó con el H265. Tampoco hace falta exagerar...

[#23 pcmaster]

#20 Depende de la potencia de CPU disponible.

[#24 pcmaster]

#18 Por eso están diseñando chips de decodificación, para no cargar el procesador con un proceso tan pesado. Además así tendrán una excusa para hacerte comprar un móvil nuevo.

[#25 Akrai]

#21 claro que no, se puede hacer por CPU, o usando la GPU, como se puede hacer en linux con vaapi, pero yo no estaba hablando de eso sino del hardware específico que se crea para la transcodificación de multimedia, que se diseña a medida para cada códec y que sí es necesario hacer si no quieres crear basura

[#26 CrudaVerdad]

#7 ¿Eres nuevo en Internet? Películas, videojuegos, series de TV y sobre todo PORNO deben almacenarse en local. Eso desaparece de Internet por diversas razones y más ahora ahora con esa miserable ola de puritanismo (disfrazado de la lucha contra la "cosificación de la mujer") que está tomando fuerza, puede llegar a bloquear sitios de pornografía.

[#27 Cehona]

#24 ¿8K en un móvil? ¿Es necesario?

[#28 sieteymedio]

#2 comentario de calidad y sabiduría.

[#29 sieteymedio]

#7 Menudo noob. Y el día en que retiren todos los videos de tu fetiche o actor preferido porque han decidido que no son legales?

[#30 eduardor2k]

#18 lo normal seria compararlo a AV1, el cual actualmente requiere una capacidad de computo muy superior a H265 logrando una reducción leve en el bitrate, misma calidad

El problema va a ser el huevo y la gallina, el codec mas soportado ganara y a estas alturas deberiamos ir viendo compresores y decompresores hardware para AV1 en cambio le falta 1 año para ver lo mismo en H266.

AV1 mejora en un 25% a H265
H266 mejora en un 50 a H265

¿Será notable la mejora? ¿o será algo marginal?

[#31 Yosemite]

#11 Ahí le has dado. ¿Para qué mejorar el software si podemos tirar el hardware actual a la basura y forzar uno nuevo?
¿Cuál es el negocio del software? La venta de hardware
Será por eso que Apple, Ericsson, Intel, Huawei, Microsoft, Qualcomm y Sony está celebrando el lanzamiento

[#32 Peka]

#7 La conexión siempre se puede caer o peor un día puede llegar un pulso electromagnético y se jodió todo Internet.

[#33 WifredoIII_ElGayu]

#23 con un buen trabuco...

[#34 sieteymedio]

"Bienvenido a pornotits.com. Necesitas un procesador con tecnología XFEFfen 266 para disfrutarla al máximo."

[#35 sieteymedio]

#13 En la pasta que te puedas gastar en hardware, como siempre.

[#36 WifredoIII_ElGayu]

#27 no. Tampoco hace falta 4k, pero como cualquier vídeo se va a grabar para ser visto en diferentes soportes, y uno de ellos va a ser la una televisión... te comes el archivazo de chorrocientos megas en el Movil...

[#37 DiCrEn]

A mi ya me parece brutal la compresión que conseguía h265... En 10 años tenemos una película 3D 4K 60fps en 20Mb 😂

[#38 torkato]

#23 Ya, claro, pero lo suyo es que esté optimizado. Si tienes que comparte un Ryzen 7 o un i9 para ver vídeos mal vamos.

[#39 Zade]

#21 y VP9 en el Apple TV a partir de tvOS 14

[#40 Desactivado]

#34 Mentiroso.
https://www.hugedomains.com/domain_profile.cfm?d=pornotits&e=com

[#41 jdkp]

#27 el nuevo codec no es solo para 8k, puedes usarlo en cualquier otra resolución y reducir la cantidad de datos a la mitad (con respecto a h265 y a 1/4 con respecto a h264)

[#42 KaborlllLLLONE]

#13 todos estos algoritmos se crean en base de aumentar considerablemente el uso del procesador/chip de decoding. A base de tirar de procesador/chip se puede reducir tanto como uno se quiera. El problemas es que no hay hardware que pueda descomprimir nada si tu algoritmo es muy exigente. Cada salto generacional es básicamente un poquito de algoritmo de compresión como la mayoría lo entiende y un aumento considerable del uso de chip.

[#43 Razhan]

#35 no me refiero al hardware (que efectivamente una implementación por hardware hará falta para descodificar esto) sino a la matemática pura que hay detrás para seguir reduciendo más y más el espacio requerido. MPEG ya era extremadamente ingenioso, y piensa todos los avances que ha habido después hasta llegar a esto.

[#44 soyTanchus]

#7 Ingente, se dice ingente.

[#45 Petetetote]

Pied Piper comprime más.

[#46 baronluigi]

#7 #12 #13 #29 #32 Aparte de que las webs de streaming, recomprimen los vídeos, con un bitrate bastante más inferior.

[#47 court]

#13 El límite de cuánto se pueden comprimir X bits viene determinado por su entropía https://es.wikipedia.org/wiki/Entrop%C3%ADa_(informaci%C3%B3n)#Codificador_%C3%B3ptimo

[#48 court]

#42 Eso que dices es sencillamente mentira. Hay límites muy claros a cuánto se puede comprimir la información que dependen de su entropía, como digo en #47. Estudia un poco sobre compresión y deja de inventar y desinformar.

[#49 Razhan]

#42 están hablando de un 50% de reducción del bitrate para mantener la misma calidad, eso no es un poquito de algoritmo de compresión. Y no, no se puede reducir tanto como uno quiera

Respecto a uso de chip, muchas de estas técnicas de compresión de vídeo que añaden codificación de bloques de bits a lo largo de un intervalo de tiempo acaban definiendo una transformación basada en vectores y álgebra lineal (para acabar diciendo coge estos lúxeles y a lo largo de x intervalo de tiempo ve moviéndolos, alargándolos, rotándolos...) así como otras operaciones específicas de imagen (como efectos de luz y color). Entiendo que esta versión será aún más agresiva a la hora de detectar estos patrones que se pueden reutilizar, y usará bloques más grandes. Esto tiene un coste bastante mayor a la hora de comprimir, pero en cuanto a descodificar, el aumento de complejidad no es mucho mayor (obviamente si solo tienes soporte de h265 y quieres procesar h266, tendrá que hacerlo la cpu, pero un chip de descodificación de h266 sera posiblemente marginalmente más complejo que uno de h265).

Es similar a compresiones tipo LZ, aumentar la distancia que el algoritmo va a buscar para detectar patrones aumenta la complejidad de compresión, pero a la hora de descomprimir, que te digan que dicho patrón está en x-23 o en x-6545 no es significativamente más complejo

[#50 Mariele]

El intituto Fraunhofer se sale. Un par de centros así en España y arreglábamos el prejuicio de que aquí solo estamos para sangrías, toros, sevillanas y palillos en la boca.

A todo esto, me alucina que sigan mejorando la compresión de vídreo así. Tengo una pregunta para algún experto: ¿Estas técnicas de codificación de vídeo hubieran tenido alguna ventaja 20 años atrás? O es que la razón por la que se usaban cosas como mpeg1 o incluso video raw a pelo era no tanto por no saber cómo hacerlo mejor sinó por limitaciones en el número de cálculos que reproductores y cámaras podían hacer?

[#51 Mariele]

Yo estoy tirando billetes contra la pantalla pidiendo vídeo con 6 grados de libertad para el espectador, pero nada rebota

[#52 MPR]

#5 La noche,... obvious.

[#53 Razhan]

#47 si, pero el tema es que aquí no se están comprimiendo bits realmente, h266 es lossy, por tanto no hay necesidad de recrear la señal original a la perfección. Los ahorros en espacio que se podrían obtener usando compresiones basadas en árboles de Huffman por ejemplo hace ya tiempo que se superaron en algoritmos de compresión de vídeo (entre otras cosas porque MPEG ya pasaba el resultado de la compresión lossy por un Huffman y entiendo que sigue siendo el caso, o similar, en h266

[#54 Peazo_galgo]

#32 en caso de pulso electromagnético fuerte se joderian todos los cacharros electrónicos incluidos tu ordenador,tablet, móvil y discos duros así que estarías jodido igualmente salvo que vivieras en un búnker reforzado bajo tierra (y aún así tengo mis dudas...)

[#55 swapdisk]

#22 ¿Ah no? Pues los servidores Plex echan humo cuando les metes pelis en H265 porque la mayoría de los clientes no soportan la deco correctamente y hacen transcoding.

[#56 jorgegv]

#48 Te has pasado con la contestación, y encima eres tú el que no tiene razón. Los límites de entropía que mencionas se refieren a la compresión/codificación SIN pérdidas.

Todos los métodos prácticos actuales de compresión de vídeo son CON pérdidas, y ahí sí, aun no está todo inventado y se puede comprimir mucho más. Todo depende del algoritmo que uses para decidir lo que quieres "perder" al comprimir.

Así que sí, a base de tirar de CPU, aun podemos comprimir tanto como queramos. Depende de la complejidad de nuestro algoritmo.

[#57 jorgegv]

#47 Solo para compresión SIN perdidas. Que no es el caso.

[#58 acastro]

#42 En realidad, cada avance viene precedido de la comprensión de lo que resulta funcionalmente más importante para el ojo humano y lo que no es tan importante.
Existe un límite para comprimir la información. Si tú generas varias secuencias de bytes con valores totalmente al azar no encontrarás ningún algoritmo capaz de comprimir esos datos.

[#59 Peka]

#54 ¿Quien te dice que no tengo mi ordenador del porn en una jaula de faraday?

[#60 jorgegv]

#50 Es lo ultimo que dices.

Hace unos 20 años, cuando empezó a popularizarse el formato MP3, recuerdo a un amigo que me decía sorprendido: "acaba de salir una tecnología que es capaz de comprimir 13 CDs de audio en un solo CD-ROM! El unico problema es que tarda 12 horas en comprimir un solo CD, y además necesitas un 486 para reproducir el fichero"

En esa epoca (sería el año 1991 o 1992), el 486 era un PC de gama media/alta.

[#61 engineer]

#60 Solo un apunte: hace 20 años estábamos en el 2000

[#62 Razhan]

#50 sin ser un experto, un poco de todo. Por un lado, la limitación en cámaras y dispositivos de grabación es el más claro. Lo más habitual es que las cámaras grabaran en un formato de compresión light tipo DV (que comprimía cada frame individualmente mediante DCT, muy similar a jpeg) y luego, una vez editado un ordenador se dedicaría a realizar la conversion del vídeo a un codec más avanzado (proceso extremadamente lento en un ordenador de casa). Este códec (como pasa en los codecs de ahora) no codifica un pixel como parte de un bloque en función de sus otros píxeles cercanos en la imagen, sino que tiene en cuenta su evolución a lo largo del tiempo. Como mencionaba en otro comentario, la complejidad de compresión es mucho mayor que la de reproducción, así que aunque hicieran falta varios segundos por frase para comprimir, la reproducción era rápida.

Muchas de las piezas claves de compresión lossy se hicieron efectivas en los 90, pero basadas en principios matemáticos más antiguos, principalmente transformaciones discretas de cósenos (DCT), propuestas en los 70, y estas a su vez basadas en transformadas de fourier.

Sin embargo, no es solo un problema de fuerza bruta. Si bien hace 20 años el hardware era una limitación, hay muchas técnicas aplicadas hoy en día que no existían hace 20 años.

[#63 court]

#56 La entropía también se aplica a la compresión con perdida: que no es más que agrupar bloques de información similares bajo un mismo símbolo. El porcentaje de información perdida define el umbral que estás dispuesto a considerar aceptable. Al margen de eso, es exactamente lo mismo.

Y no, tirando de CPU no puedes comprimir tanto cuanto quieras. No puedes comprimir un mega en un bit, salvo que estés dispuesto a perder el 100% de la información claro: y eso no tiene nada que ver con el algoritmo, ni con el uso de CPU.

[#64 court]

#53 #57 go to #63

[#65 Jakeukalane]

#43 pues habrá un límite log (n) (o colo de llame) normal ¿no? Lo que al parecer se está lejos...

[#66 javipe]

#21 Lo puedes hacer por software siempre, y decodificar que suele ser un poco menos pesado, lo puedes hacer en tiempo real. Otra cosa es que si lo haces por hardware normalmente lo puedes hacer con mucha más eficiencia, lo cual en dispositivos móviles redunda en ahorro de la batería.

[#67 javipe]

#30 Me parece muy optimista decir que H266 reducirá un 50% sobre H265. Habrá que verlo y en qué condiciones. Como siempre influirá los que estén detrás de cada Codec. Me sorprende que algunos están poniendo los huevos en las de los dos cestas AV1, y H266. Los miembros que gobiernan el estándar AV1 son Netflix, Amazon, Google, Apple, Microsoft, Cisco, IBM, ARM, Intel, Facebook, Nvidia, Samsung, Mozilla y Tencent.
Me hace pensar que AV1 va a tener más soporte detrás. Habrá que ver si H266 cumple expectativas porque será la manera de derrotara a AV1

[#68 Razhan]

#63 se aplica en el sentido de que una compresión lossy es una reducción de la entropia hecha a propósito. En una compresión lossless efectivamente la entropia determina tu límite. En una lossy, es simplemente una propiedad, pero no es mi factor limitante, ya que la entropia de la entrada y de la salida son distintas. No entiendo su relevancia para hablar de un límite teórico para la efectividad de compresión lossy de vídeo

[#69 Desactivado]

#2

Pixels del tamaño 320x200 .... (lo que era una CGA antigua)

[#70 BM75]

#55 Es un tema bastante específico, no una "nueva necesidad" que afecte a mucha gente. No conozco a nadie que se cambiara de ordenador, tablet o móvil expresamente solo porque saliera H265.

[#71 Razhan]

#63 por cierto, compresión lossy no es agrupar bloques de información similares bajo un mismo símbolo, eso solo es el último paso. Cuando aplico un MDCT a un archivo de sonido para eliminar ciertas frecuencias y crear un mp3, no estoy agrupando bloques de información similares. Estoy eliminando información (y entropia), pero lo estoy haciendo de una forma muy específica basándome en las limitaciones del oído humano. Lo mismo cuando en compresión de imagen me baso en mantener información de luminancia y desechar parte de la información de crominancia. No es la similitud de los símbolos la que me permite hacer eso, sino la distribución de conos y bastones en el ojo humano limitando nuestra visión en color

[#72 BM75]

#42 A base de tirar de procesador/chip se puede reducir tanto como uno se quiera.

Evidentemente, NO es cierto.

[#73 court]

#68 Sí es un factor limitante y el proceso es exactamente el mismo: sin extenderme mucho, puedes pensar en la compresión con pérdida como en el siguiente proceso (dicho rápido y mal, pero equivalente a efectos prácticos):

1) Aplicas un filtro a la entrada para eliminar la información que no te interesa o agrupar/reducir la granularidad/precisión de la menos relevante.
2) Aplicas compresión.

Como ves, lo que determina la pérdida es el filtro aplicado a priori, el resultado del filtro (tu entrada para compresión) tiene cierta entropía y supone un límite como siempre. La compresión con pérdida trata de encontrar mejores filtros que eliminen/agrupen información no relevante para la vista u oído humanos de forma que el impacto en la percepción sea mínimo. Una vez eliminado todo lo que los sentidos humanos no perciben, lo que queda, que es bastante, se comprime con las mismas limitaciones de siempre (las cuales, son matemáticas y absolutas).

En resumen: la compresión con perdida es solo añadir un filtro que transforma la entrada antes de una compresión sin pérdida.

[#74 arisma]

#69 El modo 13

[#75 Manolitro]

#59 Y la red eléctrica que lo alimenta?

[#76 pedrobz]

#59 Depende de la fuerza del pulso, la jaula te puede servir o no. Aparte, tiene que estar dentro de la jaula en el momento del pulso, y la jaula debe también estar cerrada, una apertura y adiós.

[#77 BM75]

#24 ¿Conoces a alguien que se cambiara de móvil solo porque salió H265?

[#78 eduardor2k]

#67 hay que tener en cuenta que unos compresores buenos importan mucho, por eso al principio de la vida de cada codec es:

codec menos eficiente pero con compresores optimizados > codec mas eficiente pero compresores menos optimizados

[#79 Razhan]

#65 oh, absolutamente hay un límite. Pero esto es como lo de transmitir datos por el aire. Hace bastante tiempo en la universidad explicaban como el aire como medio de transmisión llegaría a su límite, y que aunque aún lograrían exprimir un poco más, tampoco podría quedar demasiado espacio para mejorar. Han pasado 15 años y ahí siguen mejorando (en justicia, muchas de las mejoras de ahora basadas en usar más frecuencias para wifi o que un dispositivo transmite en múltiples canales si estos están libres no está aumentando el límite teorico

[#80 court]

#71 lo elaboro en #73, y hay muchas más formas de las que describo dependiendo de qué clase de información quieres comprimir, pero eso no cambia que al final haces una compresión matemática sin pérdida limitada como tal.

[#81 Razhan]

#73 Si, pero el 99.99% de lo que define un codec como h265 es ese “solo añadir un filtro que transforma la entrada”. La compresión sin pérdida que se hace después es poco más que una nota al pie de página diciendo “Una vez realizado todo esto, aplican Huffman encoding”.

[#82 Desactivado]

#17 Y te fundes la batería en cero coma... Por software lo puedes hacer en un ordenador de sobremesa, pero lo bueno de estos chips es que decodifican consumiendo una fracción de energía.

[#83 Desactivado]

#42 Que me despierten cuando consigan codificar 8K a un bit por segundo

[#84 court]

#81 En efecto; por eso la afirmación a la que respondía en mi primer comentario era falsa: no puedes comprimir todo lo que quieras tirando de CPU y siempre tienes un límite absoluto; una vez que has descartado la información que no te interesa estás tan limitado como siempre.

[#85 Peka]

#75 Bateria intercambiable y bateria se recarga fuera de la jaula

[#86 Peka]

#76 Vivo en ella

[#87 Desactivado]

#45 Pied Piper SIEMPRE comprimira más

[#88 Cehona]

#41 Intenta reproducirlo a 4320p60 (8K) sin lag y a 1080p60 (en las opciones del video)

[#89 swapdisk]

#70 no hombre, pero muchos no lo usamos por eso. Requiere hard mucho más moderno y potente. Cierto que ahorras espacio, pero comprimir en H265 también lleva más tiempo.

[#90 Desactivado]

#45 Se dice middle-out.

[#91 Razhan]

#84 ese comentario original de que podías reducir tanto como quisieras es obviamente falso. Pero te has metido en un berenjenal tu solo añadiendo conceptos que aplican a compresiones lossless y luego te has agarrado a un clavo ardiente para justificar el por que ese concepto era aplicable en este caso y por el camino dejando mensajes (algunos escritos de manera turbia, otros directamente falsos) que lo único que hacen es complicar aún más un tema que ya de por si es complejo para gente que no esté familiarizada

[#92 blade]

#86 ¿Como tienes internet dentro de una auténtica jaula de Faraday?

[#93 luisfeser]

#13 totalmente
Yo paso a 265 todos los videos del móvil y pasan de ocupar 200megas a 25megas. Cerca de un 90% de menos espacio.
Y ya he parece increíble. Que ocupen unos 15 megas, más increíble todavía

Lo del HW, all final en unos años todos los procesadores soportaran 265, 266

[#94 Peka]

#92 He dicho que es mi ordenador del P0rn hay que seguir la conversación.

[#95 blade]

#33 Con buena *** bien se ***

_{(con buena cpu bien se decodifica, mal pensados)}

[#96 Desactivado]

#74

19 ó 13H , pero eso es VGA, CGA era más limitadita.

https://en.wikipedia.org/wiki/Mode_13h

[#97 Razhan]

#83 mañana mismo. Espero que no seas muy exigente con el frame rate, va a estar algo lejos de 60 fps. Mejor si empezamos a hablar de fph, o mejor aún, fpd. Creo que podría sacar casi 2fpd.

Corrección, me he equivocado por un orden de magnitud, que tal si vamos a fpa?

[#98 court]

#91 Puedes decirme qué he dicho que sea falso? La compresión con perdida, a pesar de nombre, no es lo que puede sugerir: es filtrado + compresión sin pérdida y se rige por las mismas limitaciones porque la compresión es la misma: la parte de filtrado NO es compresión, es filtrado. Por otro lado, no he reducido en absoluto el comentario, si hay otras conclusiones que puedas sacar de lo que dice (voy a ignorar por tu bien la frase en negrita), por favor, muéstralas.

Y no considero que me haya mentido en ningún berenjenal Cuando tengo un rato libre no me importa rebatir la desinformación y las tonterías que se dicen por váyase a saber usted qué motivo; especialmente cuando el autor habla tratando de sentar cátedra sobre un tema que desconoce.

[#99 seby]

#79 Vaya por delante mi ignorancia, pero las ondas electromagnéticas son de frecuencias infinitas, con lo cual podrás aumentar la frecuencia (que es proporcional a la potencia) hasta el límite de que sean nocivas con los seres vivos.
Una vez se llegue al límite, se podría utilizar doble o triple canales a la vez para transmitir la información.
El ancho de banda con esa supuesta tecnología sería infinito.

[#100 Desactivado]

#12 Bienvenido a la epoca de los favoritos en tu navegador.