Ajustando los Archivos de Video Retro para Mostrar en la Web Moderna utilizando WebGL en React

Gracias, soy Travis Tykemany3 McGeehan. Soy un desarrollador full-stack en Gordon Food Services y administrador del equipo TaskBot y embajador de Task Videos. También soy autor de TAS, así que acabo de decir la palabra TAS muchas veces. Probablemente se estén preguntando qué es un TAS. Bueno, eso es lo primero de lo que hablaremos, preservar nuestras grabaciones de juegos retro de la escena TAS para los espectadores modernos con WebGL.

Entonces, ¿quién es TaskBot y qué es el equipo TaskBot? TaskBot es como un piano de jugadores para consolas de juegos retro, especialmente las consolas de la era NES, SNES y N64 con la ayuda de la interfaz Game Boy en el Game Boy. El equipo TaskBot ayuda a traducir las speedruns asistidas por herramientas, jugando juegos de video lo más rápido posible con la ayuda de herramientas para retroceder fotograma a fotograma a través de esos juegos de video y crear la secuencia de entradas más rápida posible. Y luego tomamos esas tendencias y las traducimos a las consolas originales y, como dije, como un piano de jugadores, introducimos esas entradas en una consola real. Hemos realizado todo tipo de presentaciones para esto en MAGFest y Games Done Quick, que requieren una captura de video precisa. Y eso nos lleva directamente a hablar sobre las herramientas que estamos utilizando para esa reproducción precisa y captura de video en la web.

Un consejo, la discusión aquí será principalmente relevante para este tipo de archivo de video retro y se centrará en las grabaciones animadas, especialmente en estos juegos de video muy, muy antiguos. Será menos relevante si tienes video filmado en vivo, excepto cuando intentamos transmitir una copia archivada de dicho video a través de la web. Entonces, hay varios problemas principales que vemos en el archivo de grabaciones de videojuegos cuando intentamos documentar estos registros de speedruns en videos TAS. El primero es la subsamplificación cromática, a un nivel muy alto, es una reducción de color. En todos los códecs de video modernos, toman el aspecto del color de los datos y lo dividen del brillo, y debido a esa división que se remonta a la diferencia entre televisores en blanco y negro y en color, las consolas de juegos originalmente no hacían esa división. Simplemente emitían información de color completa junto con información de brillo, y cuando se introducen en un códec de video más moderno que tiene esa división, pierden parte de sus datos y obtienes un video de peor calidad, especialmente en estas resoluciones de juego muy bajas como 240p. Si solo tienes la mitad de los datos de color de 240, ahora solo estás hablando de 120 líneas de color y eso no es mucho color. Esto realmente no sucedió con la subsamplificación en los juegos de video hasta la era de GameCube. Entonces, en estos juegos de video muy antiguos donde estamos haciendo estos registros de speedrun, a menudo en la era de NES a N64, no vemos esta reducción de color incorporada en los juegos, y luego vemos corrupción en la grabación de video.

El segundo problema que tenemos es que estas resoluciones muy pequeñas tienen relaciones de aspecto estiradas. Estas también son resoluciones muy pequeñas para empezar, y tenemos que ampliarlas a las pantallas modernas. Hablamos de pantallas como el OLED LG G3, o el Samsung S95B, o todo tipo de... ahora están saliendo monitores de juego reales para estas pantallas extremadamente precisas en cuanto al color. Queremos poder mostrar en esas pantallas, pero no necesariamente podemos hacerlo en las resoluciones originales. Porque estas pantallas son de 1440p o 4K. Entonces tenemos que estirar hasta la pantalla completa. Y también tenemos el problema de que las resoluciones originales no tenían píxeles cuadrados. Cuando se reproducían en CRT, los CRT reproducían cada entrada como una fuente 4-3. Entonces, si el juego que llegaba era de 256x240, como en el NES y era casi una imagen cuadrada, se estiraría para convertirse en un rectángulo en la pantalla CRT resultante. Entonces, necesitamos replicar ese estiramiento en el monitor. Pero si haces eso cuando almacenas la grabación, digamos que hiciste un video de NES y lo almacenaste en 320x240, obtendrías artefactos extraños donde tal vez un píxel se vea bien, y luego el píxel a su derecha está a medio camino entre dos, y ahora tienes un artefacto allí.

Entonces, quieres poder almacenar estos registros en las resoluciones originales, sin estirar, de 256x240 y luego hacer ese estiramiento a 320 cuando llegues a la resolución final de visualización, como 1440 o 4k. También tenemos un problema cuando hacemos ese escalado en el códec de video normal, o en el reproductor de video normal, el reproductor de video HTML5, todo se hace con un algoritmo llamado Bilineal, que es genial para las grabaciones de películas, donde si quieres interpolar entre un píxel y el siguiente, tiene sentido promediar los dos. Pero en el sentido de los juegos de video de arte de píxel, no quieres tener todos esos bits de color adicionales. En el juego de video original, pasaba directamente de ser un color a otro color. Entonces, no funciona hacer esa interpolación bilineal. Podría usar otros algoritmos para el arte de píxel en su lugar.

En cuarto lugar, tenemos el problema de la compresión con pérdida. Casi todos los videos web tienen pérdida, lo que significa que hay una serie de artefactos en la compresión para poder transmitirlos a través de la web. Por lo tanto, tenemos nuestras propias técnicas para hacer cosas sin pérdida para estos videos muy antiguos y más pequeños. Y en quinto lugar, y por último, tenemos esta corrupción intencional de la señal de video CRT y compuesto como diseño de arte. Entonces, muchos de estos juegos originales de NES, SNES, no solo estaban desarrollando las señales para mostrar una imagen, sino que realmente las estaban desarrollando con la intención de que se corrompieran de la misma manera que un CRT corrompería una imagen, incluso estos monitores de color de 4k y 1440p realmente precisos todavía tienen una ligera corrupción en las imágenes. En aquel entonces, los CRT tenían mucha corrupción y esta corrupción se usaba para crear colores adicionales, como usar dithering o tener un patrón de tablero de ajedrez para hacer una transición gradual entre dos colores y tener en realidad más color del que el propio sistema podía crear aprovechando los artefactos causados por el CRT.

Entonces, teniendo en cuenta todos esos problemas, veamos cómo se ve eso en la práctica. Esto es de lo que hablé sobre el suavizado bilineal, que es el del medio en esta comparación. Así es como se reproducen casi todos los videos si solo ves un video en línea como YouTube, Twitch, todos ellos tendrán ese filtrado para adaptarlos al tamaño de tu navegador. A la izquierda, puedes ver un algoritmo diferente llamado Punto. Entre la parte superior e inferior, se ven las diferencias en dos fotogramas sucesivos de un video. En el fotograma superior, el escudo de Link en esta imagen está en un píxel, y en el siguiente fotograma está en un píxel diferente. Y debido a cómo funciona el punto, será más ancho en uno de esos fotogramas que en el siguiente si estás escalando por un factor no entero. Digamos que tu fuente es 240, como en el NES. Y estás escalando a, no 960, 4 veces, sino a 1080p, una resolución de escritorio normal, 4.5 veces. Y si aumentas desde un píxel de origen, 4.5 veces, bueno, el vecino más cercano, o punto, dice que solo puedes aumentar 4 o 5 veces. Por eso, en un fotograma del video en la parte superior, ha aumentado 5 veces en el escudo de Link, y luego en el siguiente fotograma, se ha movido y ahora solo aumenta 4 veces para esa línea. Porque a lo largo de todo el video, cada línea vertical será 4 o 5, de ida y vuelta. Y esto crea un efecto de temblor y ondulación. Y a la derecha de los tres, se ve Área, que es el algoritmo que nos gusta usar para esta reproducción de extrema precisión, es como la proyección de Mercator. En la proyección de Mercator, cuando se habla de mapas, hay toda esta distorsión de las formas de los continentes, debido a tratar de hacer que las cosas sean rectas en latitud y longitud, y eso es lo que vimos en Punto. Mientras que Área trata de comprometerse entre tener una latitud y longitud rectas, y tener formas adecuadas. Entonces, Área tiene una forma adecuada del escudo, siempre tiene el mismo número de píxeles de ancho, y eso es porque si estuviéramos aumentando como cuatro veces y media, tendría cuatro píxeles regulares, y luego para esa mitad, volvería a hacer bilineal y promediaría solo para esa línea donde sea necesario.

Mientras que el escalado bilineal mostrará el escudo completo en un cuadro y luego mostrará el 80% del escudo y parte del suelo detrás en el siguiente cuadro, y luego mostrará el 60% en el siguiente. Por eso el algoritmo de área es realmente útil. Obtenemos una especie de compromiso entre los problemas del punto y el bilineal en lugar de solo tener esta difuminación que preferiríamos más para una grabación de película.

Podemos ver esto nuevamente en Atari, Atari la clásica controversia 557, el elemento humano, mostramos los artefactos, todas estas cosas diferentes de las que hablamos apiladas juntas y realmente no se ve tan mal hasta que lo comparas con la fuente de área escalada sin adulterar. Puedes ver que solo hay pequeños, pequeños fragmentos de artefactos alrededor de los bordes del cinco y el cuatro de la imagen. Y por último, esto es lo mismo, pero hablando de la simulación de CRT. Así que dije cómo el CRT puede afectar la imagen de la manera en que el artista lo pretendía. Tenemos la capacidad en RGBScaler.com de reproducir ese CRT donde cada subpíxel rojo, verde y azul individual se amplía. Y también algo llamado líneas de exploración se amplían. Entonces, cuando se mostraba metraje de NES en un antiguo CRT, todo el metraje en ese entonces era entrelazado. Y eso significaba que mostraría las líneas horizontales como un peine, como puedes ver con mis dedos donde hay una imagen y luego hay un espacio y hay una imagen y luego hay espacio y espacio. Así es. Lo que ocurría en los juegos de NES, debido a que la consola misma no estaba creando metraje entrelazado, simplemente, en lugar de en el segundo campo, mostrar la información faltante y luego volver y hacer esto y luego rellenarla nuevamente, en cuadros o campos sucesivos de datos, el NES pintaría sobre las mismas líneas. Así que tendrías este espacio vacío constante entre cada línea horizontal. Y eso es lo que esta simulación de CRT ayuda a agregar, tener esas líneas de exploración, es como se llaman. Y luego la máscara de ranura es ese efecto de reproducción de la ampliación de los subpíxeles rojo, verde y azul.

Para resumir nuevamente, esto es lo que la mayoría de los videos se ven cuando los ves en un elemento de video normal. Esto es lo que nos gustaría que se vean para las grabaciones de juegos retro. Y esto es lo que realmente nos gustaría que se vean si el artista del videojuego pretendía que se vea en un CRT y diseñando en torno a eso. Aquí es donde llegamos a la parte principal de JavaScript y React de la charla y por qué construimos el sitio rgbscaler.com. Utilizamos una serie de técnicas en combinación para mitigar esos factores y preservar las grabaciones nítidas de estos juegos de GameBoy de muy baja resolución. Tengo un código QR que puedes usar para abrir y este código QR debería funcionar tanto en Android como en iOS en cualquier teléfono moderno para mostrarte el video codificado en AV1 o H265 y luego ampliarlo exactamente al tamaño de tu dispositivo. Y esto utiliza el algoritmo de área, que mencionamos antes, que originalmente se desarrolló para LibRetro y toda la escena retro, pero también se adaptó a OBS. Por lo tanto, puedes usar el algoritmo de área en OBS y se extrajo de OBS para su uso en RGBscaler.com. La simulación de los efectos CRT que mostramos también es posible en este sitio, RGBscaler.com. La única restricción real es que si simplemente vas a RGBscaler.com en tu navegador sin usar este código QR, para reproducir cualquier video que desees a través de un enlace o también puedes cargarlo desde tu computadora, pero si deseas reproducirlo desde un enlace, debes tener el sitio con ese enlace aceptando núcleos anónimos y publicitando núcleos anónimos. Es una pequeña restricción. Es debido a la forma en que Canvas funciona con HTML5, pero aparte de eso, puedes reproducir cualquier video que desees. Y si tienes otro en Internet, simplemente descárgalo primero y reprodúcelo a través del proceso de carga de archivos en RGBscaler.com. Pero nuevamente, el código QR tiene un video preestablecido para que lo veas y veas la mejor calidad posible con todos estos efectos en combinación.

Y esto se puede clonar fácilmente también. Hay una biblioteca, React RGB Scaler, en NPM que puedes usar para llevar la tecnología y reproducirla en tus propios sitios. Así que repasemos algunas de las técnicas que el sitio utiliza. Las primeras dos son los codecs de video AV1 y H.265. AV1 amplía el soporte para 444 y grabaciones sin pérdidas, lo que soluciona los problemas de reducción de color y las grabaciones con pérdida y los artefactos resultantes. Es compatible con Firefox y Chrome en Android y con los navegadores de escritorio basados en Chromium. Permite un almacenamiento eficiente y un escalado adecuado de las grabaciones de arte de píxeles al ser sin pérdidas en ese formato de resolución original pequeño. H.264 puede ser más eficiente para los modos sin pérdidas, pero debido a su falta de compatibilidad, nos quedamos con AV1 para este lado de Android. Y luego la segunda mitad es H.265. Y aquí es donde entramos en el código, cuando estás utilizando AV1 y H.265, debes especificar estos tipos de fuentes de manera muy precisa en un conjunto de fuentes. Una fuente es el lado codificado en AV1, y se escribe con Video WebM porque debe estar en el contenedor WebM. Y luego la segunda es publicitar no solo que es un contenedor MP4, sino específicamente que es el codec de video HVC1 o H.265, y eso permite que Safari y los dispositivos iOS detecten que hay una fuente de video que pueden utilizar. Y luego las complementarias, Android puede utilizar la fuente AV1. Un dato curioso es que en realidad no podemos proporcionar una tercera opción de respaldo con una fuente H.264 debido a problemas con iOS y Safari. No respetan el orden de estas fuentes y, si ven una fuente H.264, siempre la reproducirán, incluso si tienes la fuente H.265 primero en el conjunto de fuentes. Esta es una información más reciente que estoy proporcionando solo para esta charla, que hemos aprendido desde la última charla que di sobre esto, hablando de cómo hemos estado haciendo estas mejoras para RGBScaler. Esto es algo completamente nuevo, que descubrimos e implementamos en el último mes o dos, que tenemos que tener solo AV1 y H.265 con estos tipos de fuentes exactos, de lo contrario, no funciona en iOS y Safari. Eso se encarga de cómo debemos pre-codificar los videos para poder aprovechar RGBscaler.com, y luego, pasando al resto, una vez que tienes ese video, lo que intentamos hacer es ampliarlo en WebGL en lugar de en el elemento de video nativo. En el elemento de video nativo, siempre se utiliza el escalado bilineal, pero no queremos bilineal. Queremos el escalado de área para tener ese compromiso para que solo tengamos píxeles nítidos en todas partes, excepto en las líneas fronterizas entre los enteros cuatro y cinco. Por ejemplo, en la toma anterior. Si retrocedemos, esto habla sobre los algoritmos de escalado, desde el punto hasta el bilineal y el área. Y si retrocedemos nuevamente, esto es por qué vamos a enviar un video a una textura WebGL. ¿Y cómo lo hacemos? En realidad, tenemos un tutorial muy útil en la documentación de MDN, Animating Textures in WebGL. Y adapté ese tutorial en gran medida para usarlo en React porque con esta estrategia, en realidad no podemos reutilizar los controles originales del reproductor de video. Si usas un reproductor de video HTML5, los controles están integrados en ese elemento. Si ocultas el elemento, también ocultas los controles. Entonces, para ampliar el video en un lienzo personalizado, también tenemos que crear todos estos controles personalizados, lo que nos lleva a querer usar React, donde podemos gestionar fácilmente el estado de todos esos controles. Y ahora, al interactuar con ese lienzo en React, lo que hacemos es establecer un atributo de referencia a un callback definido en un hook personalizado y utilizamos callbacks para realizar una serie de configuraciones de WebGL en la inicialización. Y puedes ver eso aquí, cosas como establecer uniformes para el programa de sombreado, para si estamos aplicando esos efectos CRT, como la intensidad de la máscara CRT y la intensidad de las líneas de exploración.

Si desactivas eso, entonces obtienes una escala de área pura para las personas que no hicieron ese tipo de diseño de arte para CRT. Pero si hay ese diseño de arte para CRT, entonces hay configuraciones para aumentar la intensidad de la máscara y la intensidad de las líneas de exploración. Y cuando entras en eso, así es como el código realmente utiliza React para gestionar el estado de esos deslizadores, aumentando la intensidad y luego enviándolo a los uniformes de WebGL. Los efectos de uso y el hook personalizado también ayudan con cosas como la dimensión del video y la intensidad del efecto.

Otra cosa con la dimensión del video, el navegador que está utilizando el usuario podría cambiar de tamaño mientras el video se reproduce, ¿verdad? Entonces necesitamos tener un efecto de uso configurado para detectar los cambios en las dimensiones del navegador y actualizar correctamente el lienzo para apuntar a las dimensiones correctas con ese cambio en el tamaño del navegador o también, en dispositivos móviles, el usuario podría girar su dispositivo si rota el dispositivo. Ahora necesitamos apuntar a diferentes dimensiones por esa razón.

Entonces, ¿cómo se actualiza la textura WebGL para los nuevos fotogramas? Bueno, también tenemos este concepto de un bucle de renderizado. Lo primero que hacemos es hacer el textImage2D, que captura el video del elemento de video y toma ese fotograma y lo envía a una textura. Y aquí es donde tenemos esa advertencia de que si estás enviando cualquier URL a RGBScaler.com, cuando vas a RGBScaler.com, hay una entrada para URL de video arbitraria. Si usas eso, tendrás un problema con el sitio web. Viene de que tiene que respetar los núcleos anónimos. Y eso se debe a que esta parte aquí con textImage2D, respeta los núcleos. Entonces, si tienes el lienzo, no se le permite leer datos de una textura que no esté completamente autenticada a través de ese ciclo de núcleo. Ahí es donde entra en juego eso. Y luego drawElements realmente toma esa textura y la dibuja en el lienzo. Y luego tenemos setAnimationFrame que setea el animation frame, que es un hook useRef.

Entonces, el hook useRef hace que todo el sitio web no provoque una nueva representación cada vez que se produce un tick de cada fotograma de animación. Pero cuando tenemos requestAnimationFrame, eso te da una devolución de llamada a un ID de ese fotograma. Y luego estamos usando un useRef con el setAnimationFrame para hacer un seguimiento del fotograma de animación. Y eso es necesario para la siguiente parte, cancelar el renderizado. Porque, por ejemplo, ¿qué pasa si alguien pausa el video? No queremos que su GPU esté generando todos estos fotogramas del mismo fotograma en segundo plano. Entonces hacemos un cancel render y cancel animation frame para finalizar ese bucle del bucle de renderizado en ese punto. Y luego podemos reiniciarlo si despausan el video. Y necesitamos hacer un seguimiento del fotograma de animación para poder hacer esa pausa y despausa allí.

Aquí tienes solo algunos conceptos básicos esenciales de la lógica del shader. No soy un experto en absoluto en la lógica del shader de WebGL. Así que probablemente esté haciendo algo monstruosamente mal, pero se entiende el mensaje. Esto es capaz de recrear nuestra máscara y nuestras líneas de exploración variándolas según la posición dentro de un píxel. Y esta textura debe muestrearse utilizando GL.linear, así que lo hago habilitado. Si muestreáramos en GL.nearest, que creerías que sería más apropiado para el video retro, entonces no podríamos hacer ese muestreo de, oh, bueno, este realmente puede estar en el centro de un píxel para obtener el más cercano.

Y luego este puede estar en el espacio lineal. Así como dije, el efecto de área se porta desde el código fuente directo de Open Broadcaster Studio. Entonces, no hay mucho que mostrar allí. Es solo el mismo efecto de área que verías en cualquier lugar que use ese tipo de escalado. Pero la clave real aquí es combinar eso con la máscara de ranura y las líneas de exploración y hacer esto en WebGL para obtener esta experiencia de reproductor web de escalado preciso.

Ahora, otra cosa genial que encontré mientras hacía todo esto es que querrías que tu lenguaje de shader, tu código WebGL real, tenga resaltado de sintaxis mientras desarrollas el complemento. Así que esta biblioteca React RGB Scaler realmente tiene eso. Si la descargas y la ves en VS Code, puedes ver el resaltado de sintaxis para el vertex shader y el fragment shader. Y eso se debe a que lo que realmente estamos haciendo es usar el complemento de roll-up string para simplemente tomar el contenido sin procesar de esos archivos e inyectarlos donde se necesitan en el código, en el tiempo de compilación de roll-up de la biblioteca. Y esto nos permite escribir el código como si tuviéramos resaltado de sintaxis completo para WebGL. Muchas veces, si estás escribiendo shaders WebGL de otra manera, simplemente tienes que escribirlos directamente en una cadena de plantilla con acento grave, y eso no se ve ideal. Así que esto es una pequeña magia adicional para facilitar el desarrollo de este complemento.

Y luego, como mencioné antes, debido a que el elemento HTML5 video debe estar oculto, los controles nativos de video también están ocultos. Así que tenemos algunas cosas como esta donde simplemente estamos utilizando una lógica simple de React para volver a implementar los controles del reproductor de video en React y tener algunos controles personalizados que el usuario puede usar para reproducir y pausar el lienzo donde finalmente se muestra el video. Otra cosa realmente genial aquí es trabajar con el escalado DPI. Entonces, si lo implementaras de manera ingenua sin comprender el escalado DPI, lo que sucedería es que el escalado del video no aprovecharía completamente la resolución del usuario o del dispositivo del usuario. Solo aprovecharía tanto como los píxeles CSS porque los píxeles CSS son un tamaño estándar que ahora se utiliza en todos los dispositivos. Entonces, por ejemplo, si tu teléfono tiene mil píxeles de ancho en la pantalla, eso podría ser solo 500 píxeles CSS. Entonces, para aprovechar al máximo la pantalla real y brindarte la imagen más nítida posible, lo que tenemos que hacer es establecer por separado el ancho del lienzo y el ancho del estilo del lienzo. El ancho del estilo del lienzo es la relación de píxeles CSS, donde no se tiene en cuenta la relación de píxeles del dispositivo. Y puedes obtener esta relación de píxeles del dispositivo de una propiedad real que está disponible en el elemento de ventana en los navegadores. Entonces, tomamos esa propiedad y la usamos para tener en cuenta la resolución completa del dispositivo y utilizar todos esos píxeles del dispositivo correctamente. Para reiterar, si lo usaras de manera ingenua sin esta relación de píxeles del dispositivo, tendrías una línea de artefacto que tendría el tamaño de los píxeles CSS y no solo el tamaño de los píxeles nativos del dispositivo. Para hacer algunas comparaciones de la eficiencia de esta técnica y por qué es realmente útil, otra cosa que podrías hacer para obtener el mismo valor es pre-codificar un video de 4K o 8K y luego, en cada dispositivo, escalarlo hacia abajo. Entonces, si un usuario tiene una pantalla de 1080p, estarían reproduciendo el video retro de 4K pre-escalado en su pantalla de 1080p. Pero luego estarías desperdiciando mucho ancho de banda en Internet, lo cual no queremos hacer. No queremos desperdiciar ancho de banda de esa manera. Entonces, puedes ver aquí los tamaños reales de estos videos son mucho, mucho más pequeños al aprovechar todas estas propiedades. Puedes ver que una codificación sin pérdida de una secuencia de Atari dragster es de solo alrededor de 119 kilobits por segundo, lo cual es notablemente pequeño en comparación con lo que obtendrías si escalas todo el camino hasta 4K, que si lo hicieras sin pérdidas podría ser de 340 a 400 kilobits. Pero YouTube simplemente asumirá ingenuamente una velocidad de bits constante para usar en un video de 4K en miles o decenas de miles. Y luego estarás gastando literalmente órdenes de magnitud más datos para enviar esta secuencia a través de la web.

Entonces, parte del valor aquí que este sitio RGB scaler demuestra no es solo que podemos mejorar la calidad de este video, sino que también podemos hacerlo utilizando cientos de veces menos ancho de banda que YouTube. Y ahora esto muestra el mismo concepto, pero en lugar del mejor escenario posible, este es un escenario intermedio para algunas imágenes de Super Mario 64 en 3D. Debido a que esto es en 3D, no tienes grandes manchas de color exactamente idéntico para combinar y crear una imagen sin pérdida perfecta. Pero aún así, en realidad solo vemos de cinco a 10 megabits por segundo de datos sin pérdida cuando usamos H264. Y obtendrías números comparables con AV1 en H265. Mencioné que tenemos que usar esto para que funcione perfectamente en iOS y Android. Verías números comparables de cinco a 10 megabits por segundo. Mientras que si fueras hasta una mejora a 4k para hacerlo sin pérdida, estaríamos hablando de 100 megabits por segundo, lo cual no es algo que realmente puedas hacer para la mayoría de los usuarios promedio. Solo alrededor del 30 al 50 por ciento de los usuarios de cable en los Estados Unidos tendrían eso, lo que haría que tu video sea inaccesible para la mayoría de las personas. Entonces, sería con pérdida. Entonces tendrías artefactos, que se ampliarían al tamaño de pantalla de este usuario, y realmente no queremos preocuparnos por todo eso. Terminamos obteniendo una mayor calidad y un menor uso de datos en toda la era de N64 con todas estas técnicas. Acabo de reiterar aquí en la diapositiva todo lo que acabo de decir. Como dije, esto funciona muy bien para juegos 2D y Atari, y sigue funcionando bien, pero no tan increíblemente. No es como órdenes de magnitud o cientos de veces mejor. Es solo alrededor de cinco veces mejor para la era de N64. Luego, más allá de eso, entrarías en cosas como que GameCube ya tiene una reducción de color de 420. Estas técnicas no serían tan relevantes de todos modos. Otra cosa realmente importante a tener en cuenta aquí es que estas comparaciones solo son relevantes con imágenes de emulador limpias o capturas de juego sin pérdida a través de una modificación HDMI desde una consola de juegos. No querrías hacer esto si solo estuvieras capturando tus cables de video habituales amarillos, blancos y rojos y los pasaras por algún dongle aleatorio que compraste en eBay. Esto es realmente algo para nuestros archivistas de videos TAS, donde trabajamos con imágenes de emulador que son perfectamente idénticas en cada píxel sin ningún ruido adicional de los cables de la consola. Si tienes ese ruido, estarás atrapado volviendo a usar imágenes con pérdida de todos modos, porque de lo contrario, tu imagen sería demasiado grande para transmitirla por Internet. Eso realmente cubre toda la charla en términos de las diapositivas. Y ahora voy a intentar mostrarte muy brevemente cómo se ve realmente el sitio en uso. Por supuesto, deberás volver a ese código QR de la diapositiva para obtener el beneficio completo para tu pantalla. Pero solo para mostrarte con fines de demostración, puedes ver algunas imágenes de Teenage Mutant Ninja Turtles aquí donde estamos mejorando la escala en mi navegador utilizando ese efecto de área. Entonces puedes ver aquí cómo en estas palabras como `round one fight` y estas barras verdes, toda esta barra es un conjunto de colores exactamente idénticos y no tienes un tipo de degradado de ese color en los bordes donde se mezcla con el blanco como lo tendrías en una mejora bilineal normal que obtendrías al reproducir este video de manera ingenua a través de un elemento de video HTML5. Entonces, sí, espero que eso haya sido útil para mostrar cómo el sitio web de videos TAS y la escena TAS están tratando de preservar imágenes de juegos retro. Si tienen alguna pregunta, no duden en ir a discord.tas.bot o hacer una pregunta en mi Twitter, en tikevin83, y estoy disponible en cualquier momento si tienen más preguntas. Gracias por ver tanto.