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.

[#5 txirrindulari]

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

[#2 Cehona]

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

[#12 ccguy]

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

[#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.

[#1 Artok]

El doble de porno en el mismo espacio

[#19 torkato]

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

[#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.

[#23 pcmaster]

#20 Depende de la potencia de CPU disponible.

[#10 Enfin...]

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

[#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

[#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

[#45 Petetetote]

Pied Piper comprime más.

[#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.

[#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.

[#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/

[#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.

[#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

[#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

[#14 Catapulta]

El flautista retorna!

[#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

[#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

[#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?

[#20 torkato]

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

[#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.

[#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.

[#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...

[#44 soyTanchus]

#7 Ingente, se dice ingente.

[#59 Peka]

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

[#140 ccguy]

#139 Vamos, que si quieres ver una peli concreta de romanos y no esta la que quieres, ve otra que también tenga leones y ya está.

[#4 vacuonauta]

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

[#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.

[#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.

[#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...

[#132 Desactivado]

#89 Al final es coste/beneficio. Yo aún tiro de H264 HLS por ser el más soportado y el que menos hace sufrir a los clientes.
Podría ahorrar disco y ancho de banda en H265 pero ahora mismo en mi caso no me compensa... veremos con el tiempo

[#17 ailian]

#16 Se puede hacer por software.

[#126 luckyz]

#23 A costa del uso de potencia. Un chip siempre va a ser más eficiente y por eso las primeras versiones van en CPU y luego salen chips que lo hacen 10 veces más rápido por 10 veces menos energía.

[#65 Jakeukalane]

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

[#27 Cehona]

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

[#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.

[#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.

[#61 engineer]

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

[#113 court]

#108 No es así, no se adivina nada.

[#124 court]

#118 Cuando haces la transformada estás eliminando detalle (salvo que cojas la serie infinita, claro ), de forma que tienes menos información que almacenar y de forma que bloques que antes eran diferentes ahora son iguales y podrán ser representados por el mismo símbolo. Esencialmente, eso es todo.

Puedes complicarlo reseteando el proceso por subdominios o por partes del flujo de información y añadiendo complicaciones al filtrado, pero al final, la operación de alto nivel que estás realizando es exactamente ésa: eliminar información poco redundante para agrupar bloques similares que serán representados de la misma forma.

[#52 MPR]

#5 La noche,... obvious.

[#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.

[#136 ccguy]

#100 poco útil si desaparece el contenido

[#138 ccguy]

#137 como los tengas todos del mismo sitio pueden desaparecer todos de golpe. O pasar a ser de pago, etc.

No sé por qué me quieres convencer de hacer las cosas como tú.

[#142 ccguy]

#141 pues si estás pensando en un capítulo por algo, quieres ese y no otro.

[#3 Peachembela]

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

[#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?

[#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.

[#74 arisma]

#69 El modo 13

[#133 rogerius]

#1 «The new chips required for the use of H.266/VVC, such as those in mobile devices, are currently being designed.»

[#123 ximiu]

#120 ja ja ja, no. Es que estoy jugando a Antimatter Dimensions, donde hay un número exacto que representa el infinito. Era una broma para mi mismo.

[#127 Naiyeel]

#51 Dale un poco de tiempo a la IA y tendremos eso y lo mas importante, videos de japonesas sin pixelar.

[#22 BM75]

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

[#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.

[#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.

[#7 Desactivado]

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

[#9 Desactivado]

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

[#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)

[#94 Peka]

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

[#96 Desactivado]

#74

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

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

[#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?

[#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 😂

[#115 Jakeukalane]

#108 siempre hay un límite de información. Me da igual que estemos a 10¹⁰⁰⁰⁰ de llegar, pero lo hay.

[#120 Jakeukalane]

#119 ¿estás intentando trolearme? Es una metáfora. Y 10 elevado a 10000 no es más que infinito.

[#125 Razhan]

#124 Como correccion (no solo a tu mensaje, tambien al mio anterior), una DCT no implica eliminacion de detalle por si misma y es reversible. En JPEG es luego cuando aplicamos las matrices de cuantizacion cuando realmente eliminamos el detalle.

Respecto a tu comentario, realmente creo que "bloques que antes eran diferentes ahora son iguales y podrán ser representados por el mismo símbolo" da lugar a confusion porque en un jpeg no hace falta que haya dos bloques diferentes que ahora son iguales dentro de la imagen, mientras que ese principio se usa en otras situaciones (como comentaba antes, indexado de color, pero tambien en MPEG)

Agradezco mucho esta conversacion, y especialmente que hayas sido respetuoso todo el tiempo. Pero donde vivo son horas inconfesables y voy a tener que desconectar

[#88 Cehona]

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

[#107 Cehona]

#103 La única ventaja a la hora de ser más eficiente y comprimir más, es el tamaño.
Pero siempre exigiendo más máquina. Muchas TV ya no pueden con el H265, no digamos el próximo H266 y no son TV de más de 3 años.
Para el streaming, igual alguna aguanta. Pero como me ocurre como cuando me venden las ventajas del mp3 a 128kbps vs 320kbps que algunos dicen no hay diferencias pero ocupan menos espacio. Si no han escuchado un audio en Flac/Lossless lo dejo.

[#8 Desactivado]

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

[#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.

[#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

[#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...)

[#75 Manolitro]

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

[#83 Desactivado]

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

[#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

[#134 mcfgdbbn3]

#11: Y que son promesas muy teóricas:
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.
Claro, como YouTube, que ahora saludan y se mueve todo el fondo alrededor de la mano.
O sea, anotan cuatro vectorcillos de movimiento, el resto va interpolado, no hay corrección de errores y pasa lo que tiene que pasar, que se arrastra el fondo como si fuera parte del frente.

[#135 mcfgdbbn3]

#13: Sería interesante ver si ese 50% es "tuneado" o si es real. Mira lo que decían de WEBP, que le daba 100 vueltas a JPEG y al final... pues eso que normalmente suelen hacer la comparación sacando a JPEG fuera de su ámbito de trabajo, no sabemos si usan las opciones que mejor lo optimizan... el caso es que un JPEG bien optimizado no queda casi atrás. Aquí hay que destacar la compresión aritmética, que en JPEG no se ha usado tradicionalmente por un tema de patentes y lo que hacen es comparar un JPEG que sigue sin usarla con un formato que sí la usa, lo cual no es una comparación real. De hecho incluso sería interesante implementar Maniac en JPEG y hacer las comparaciones así en los formatos que usen Maniac, si bien no es realista porque JPEG no lo usa, pero puede ayudar a interpretar si la forma de tratar la imagen es mejor o peor. Como dato: un formato sin pérdida como PNG que usa Maniac en vez de Deflate, comprime una barbaridad, hasta un tercio respecto de un PNG ya optimizado, se llama FLIF:
https://en.wikipedia.org/wiki/Free_Lossless_Image_Format

Y también es típico mirar medidas que a lo mejor matemáticamente están bien, pero que no siempre se corresponden con lo que vemos, como el PNSR, que a lo mejor una imagen es mejor que otra, pero luego la miras y está demasiado difuminada y a nuestro ojo representa la realidad peor que la otra. Aquí añadiría lo que digo en otro comentario: si a un algoritmo PNSR le importa poco que se mueva el fondo al mover el frente, a mi como humano sí me importa porque se me hace "raro" de ver.

[#143 Nova6K0]

Sigo sin saber a que se refieren a mitad de espacio con la misma calidad en serio ni HEVC (H.265/X.265) ni H.264/x.264 cumplen eso, salvo que se refieran a tener un vídeo en formato puro o sin comprimir, que eso nunca lo probé y pasarlo a HEVC. Porque hice decenas de conversiones y en ninguna ocupa menos con la misma calidad. Otra cosa es si reduces el bitrate, claro.

Salu2

[#57 jorgegv]

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

[#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.

[#64 court]

#53 #57 go to #63

[#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

[#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.

[#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

[#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.

[#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.

[#92 blade]

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

[#95 blade]

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

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

[#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.

[#101 Cyrus_]

#54 Entiendo que el dice que el pulso electromagnetico esté cerca del servidor de la nube, pero lejos de sus discos duros.

[#109 court]

#104 Bueno, estamos de acuerdo en casi todo. Todas mis respuestas iban a desmentir el primer comentario, no a nada que tú haya dicho específicamente.

Discrepamos en:
- La entropía sigue siendo limitante en compresiones con pérdida. Tú dices que no, pero lo es. Que consideres el umbral de aceptación del filtro como OTRO factor limitante está bien, es discutible, pero está bien; pero ello no elimina que sigas limitado entrópicamente.
- Mi mensaje: podría haberlo explicado mejor, pero aplicar bloques de información similar bajo un mismo símbolo (que puede ser el vacío) es el equivalente a filtrar + comprimir. Al final del proceso, es la operación que estás realizando, el filtro es el que "organiza" qué información agrupar y cuál desechar (incluyendo información de precisión). Como digo, podría explicarse mejor, pero matemáticamente el símbolo vacío es un símbolo más por lo que lo he tratado como tal al definir la compresión con pérdida.

[#116 court]

#114 Y lo grande o pequeña que es esa diferencia, viene determinada por la entropía del original.

Formalmente lo que estás haciendo es una descomposición incremental de la señal, no deja de ser otra forma de filtrado.