TECNOLOGíA, INTERNET, JUEGOS
276 meneos
1839 clics

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.

| etiquetas: fraunhofer , vídeo , compresión , h266
145 131 0 K 280
145 131 0 K 280
Comentarios destacados:                                
#7 el porno es de las cosas que o guardas o puedes no volver a localizar.
#7 #12 #13 #29 #32 Aparte de que las webs de streaming, recomprimen los vídeos, con un bitrate bastante más inferior.
#12 Bienvenido a la epoca de los favoritos en tu navegador.
#100 poco útil si desaparece el contenido
#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.
El doble de porno en el mismo espacio :-O
#1 8K para que luego te pixelen los japoneses.
#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... :troll:
#2 La codificación del C+ del siglo XXI. :troll:
#2 comentario de calidad y sabiduría. :-)
#2

Pixels del tamaño 320x200 .... (lo que era una CGA antigua)
#69 El modo 13
#74

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

en.wikipedia.org/wiki/Mode_13h
#96 Sí, yo hablaba por la resolución y los 64000 bytes de imagen en crudo xD

Saludos.
#2 4K es magnífico, casi injustificable. 8K no me lo imagino, lo tengo que ver.

Ahora bien, esto es justo lo que le hacía falta a DP 1.4 para poder mover 8K a 60Hz.
#1 ¿Aún almacenas porno? Bienvenido a la época del streaming. Xvideos, Pornhub hay cantidad indigente de material porno sin almacenar nada.
:troll:
#7 El streaming es muy bonito hasta que deja de estar lo que quieres. Mejor invertir en discos duros.
#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?
#7 La conexión siempre se puede caer o peor un día puede llegar un pulso electromagnético y se jodió todo Internet.
#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...)
#54 ¿Quien te dice que no tengo mi ordenador del porn en una jaula de faraday? :troll:
#59 Y la red eléctrica que lo alimenta? :troll:
#75 Bateria intercambiable y bateria se recarga fuera de la jaula :troll:
#75 bateria de patata, 100% libre de emisiones e independiente de red electrica {0x1f602}
#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.
#76 Vivo en ella :troll:
#86 ¿Como tienes internet dentro de una auténtica jaula de Faraday? :popcorn:
#92 He dicho que es mi ordenador del P0rn :troll: hay que seguir la conversación.
#54 Entiendo que el dice que el pulso electromagnetico esté cerca del servidor de la nube, pero lejos de sus discos duros.
#7 Ingente, se dice ingente.
#1 Y una CPU así de grande para poder verlo.
#1 «The new chips required for the use of H.266/VVC, such as those in mobile devices, are currently being designed.»
#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
Pied Piper comprime más.
#45 Pied Piper SIEMPRE comprimira más :-D
#45 Se dice middle-out.
#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.
#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
#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…   » ver todo el comentario
#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.
#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”.
#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.
#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
#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…   » ver todo el comentario
#98 la frase en negrita no es mia, si hay algo que claramente los dos estamos de acuerdo es que esa frase es completamente falsa

Efectivamente, toda compresión lossy es una parte de filtrado y después una aplicación de una compresión lossless. Pero cuando alguien te dice algo como que h266 comprime el doble que h265, no te está diciendo que la parte de compresión lossless de h266 es más eficaz, te habla de la parte de filtrado. Porque la parte de compresion lossless no ha cambiado en 25 años.…   » ver todo el comentario
#73 Nada te impide comparar el stream obtenido con el real y mandar la diferencia por otro canal.
#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
#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.
#43 pues habrá un límite log (n) (o colo de llame) normal ¿no? Lo que al parecer se está lejos...
#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
#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.
#99 El "ancho de banda", lo que significa es que si transmites más información estás ocupando las frecuencias adyacentes también. Usar frecuencias muy altas tiene límites, como entrar en la banda visible, que eso no lo vas a hacer (pero hay satélites que lo hacen, para radars). La transparencia de los materiales de construcción baja a casi nada por encima de los 6GHz.
#79 Una evaluación de hace algunos años decía que tenemos frecuencias de sobra, las cuales, debidamente, usadas, son más que suficientes para todos los datos que estamos transmitiendo.
#65 Lo que hace un algoritmo de compresión es adivinar la siguiente imágen de una secuencia. Si la adivina exactamente no hay que transmitir nada más. Si la diferencia es pequeña, se transmitirá poca cosa. La cantidad de cosas adivinables no creo que tenga un límite.
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?

www.videoproc.com/media-converter/vp9-vs-h265.htm

Sobre todo en la necesidad de hardware y el consumo de…   » ver todo el comentario
#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.
#24 ¿8K en un móvil? ¿Es necesario?
#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...
#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)
#41 Intenta reproducirlo a 4320p60 (8K) sin lag y a 1080p60 (en las opciones del video)
www.youtube.com/watch?v=FrKNa3hruBw
www.youtube.com/watch?v=n-RjGEWW3nk
#88 No entiendo que intentas decir. Por si acaso voy a aclarar lo que pretendo decir en mi anterior comentario:

De este nuevo codec (h266) no solo se van a beneficiar los videos en 8k, también se podrán codificar videos en 1080p o 4k y reducir su tamaño manteniendo la calidad.
Lo mismo sucede con h265.

Al reproducir los videos que pones, el video en 8k me va a saltos. ¿Y?
Ni siquiera tengo resolución 8k en el portatil. Pero puedo reproducir el video en 1080p codificado con el codec VP9 (similar en rendimiento al h265 - usado para 4k), por lo tanto me estoy beneficiando de un codec más eficiente que el h264 con una resolución "solo" 1080p.
#24 ¿Conoces a alguien que se cambiara de móvil solo porque salió H265?
#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?
#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
#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
#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…   » ver todo el comentario
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
#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
#16 Se puede hacer por software.
#17 por software se puede hacer, pero va fatal.
#20 Depende de la potencia de CPU disponible.
#23 con un buen trabuco...
#33 Con buena *** bien se ***

(con buena cpu bien se decodifica, mal pensados)
#95 lo iba a poner, pero no me salían términos tan apropiados

Hermano separado al nacer
#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.
#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.
#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.
#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.

www.reddit.com/r/apple/comments/b0nwps/safari_to_support_vp8_video_cod
#21 y VP9 en el Apple TV a partir de tvOS 14
#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.
#11 No pasó con el H265. Tampoco hace falta exagerar...
#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.
#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.
#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.
#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
#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 xD
Será por eso que Apple, Ericsson, Intel, Huawei, Microsoft, Qualcomm y Sony está celebrando el lanzamiento
#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. xD
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. xD
El flautista retorna!
Me parece absolutamente increíble como siguen logrando exprimir aún más los algoritmos de compresión. Donde está el límite?
#13 En la pasta que te puedas gastar en hardware, como siempre.
#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.
#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.
#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.
#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.
#42 A base de tirar de procesador/chip se puede reducir tanto como uno se quiera.

Evidentemente, NO es cierto.
#42 Que me despierten cuando consigan codificar 8K a un bit por segundo :troll:
#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?
#13 El límite de cuánto se pueden comprimir X bits viene determinado por su entropía es.wikipedia.org/wiki/Entropía_(información)#Codificador_óptimo
#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
#47 Solo para compresión SIN perdidas. Que no es el caso.
#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
#13 Se puede hacer mucho más, el límite está en un protocolo donde le das la descripción del personaje y dices: "ahora que ande más deprisa mientras mastica chicle poniendo cara de felicidad", el algoritmo simula eso y solo hay que transmitir pequeñas diferencias, sin duda debidas a la creatividad del director.
#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…   » ver todo el comentario
deberían colocarles otros nombres, esa nomenclatura lleva a confundir.
#3 confunde, sí, pero mejor eso que ir de ultracompression a ultracompression supra y de ahí a ultracompression supra top, etc
#3 ¿qué te confunde?¿la H? h264, h265, h266
#5 La noche,... obvious. :-D
#3 Hay otra nomenclatura:
H264 = AVC (Advanced Video Coding)
H265 = HEVC (High Efficiency Video Coding)
H266 = VVC (Versatile Video Coding)
#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).
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 {0x1f602}
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?
#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.
#60 Solo un apunte: hace 20 años estábamos en el 2000 :troll:
#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)…   » ver todo el comentario
#50 Ambas cosas el formato mp3 no se hacía con mas calidad por que las maquinas no podrían hacer nada con el... y muchas de las técnicas que usan los codecs actuales no existian de aquella, asi que ambas.
Yo estoy tirando billetes contra la pantalla pidiendo vídeo con 6 grados de libertad para el espectador, pero nada rebota
#51 Dale un poco de tiempo a la IA y tendremos eso y lo mas importante, videos de japonesas sin pixelar.
"Bienvenido a pornotits.com. Necesitas un procesador con tecnología XFEFfen 266 para disfrutarla al máximo."
«12
comentarios cerrados

menéame