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

Rate this content
Bookmark
Slides

- Antecedentes sobre por qué los archivos de video retro necesitan escalado personalizado

- Implementación de un reproductor de video WebGL en lienzo en React con hooks personalizados

- Agrupando shaders WebGL desde archivos separados para resaltar la sintaxis GLSL

- Demostración en vivo de aplicaciones para imágenes de consolas de videojuegos retro, cintas VHS, etc.

31 min
06 Jun, 2023

Video Summary and Transcription

Travis Tykemany3 McGeehan, un desarrollador full-stack en Gordon Food Services y administrador del equipo TaskBot y embajador de Task Videos, habla sobre la preservación de imágenes de juegos retro de la escena TAS para los espectadores modernos con WebGL. Explica el papel de TaskBot, un piano de jugadores para consolas de videojuegos retro, y cómo el equipo de TaskBot traduce las carreras de velocidad asistidas por herramientas para crear la secuencia de entradas más rápida posible. También destaca los problemas principales en la preservación de imágenes de videojuegos, incluyendo la submuestreo de croma y las relaciones de aspecto estiradas en resoluciones pequeñas. Los desafíos en la preservación de imágenes de juegos retro incluyen almacenar registros en las resoluciones originales sin estirar y evitar la interpolación bilineal. Diferentes algoritmos, como punto y Área, producen efectos distintos al escalar imágenes. Las técnicas utilizadas en rgbscaler.com para preservar imágenes nítidas de juegos GameBoy de baja resolución incluyen el uso del algoritmo de Área, videos codificados en AV1 y H265, y la capacidad de reproducir videos con efectos CRT. Los códecs de video AV1 y H.265 se utilizan para admitir imágenes sin pérdida y un escalado adecuado de imágenes de arte de píxeles. Se crea un lienzo personalizado con controles personalizados utilizando React para ampliar el video en WebGL, y se utiliza el algoritmo de escalado de Área en lugar de bilineal. La textura WebGL se actualiza utilizando un bucle de renderizado, y la lógica del shader recrea la máscara y las líneas de exploración basadas en la posición del píxel. La biblioteca React RGB Scaler permite resaltar la sintaxis del shader de vértices y del shader de fragmentos, lo que facilita el desarrollo. El sitio RGB scaler demuestra el valor de mejorar la calidad del video mientras se utiliza significativamente menos ancho de banda que YouTube.

Available in English

1. Preservando la grabación de juegos retro con WebGL

Short description:

Travis Tykemany3 McGeehan, un desarrollador full-stack en Gordon Food Services y administrador del equipo TaskBot y embajador de Task Videos, habla sobre la preservación de la grabación de juegos retro de la escena TAS para los espectadores modernos con WebGL. Explica el papel de TaskBot, un piano de jugadores para consolas de juegos retro, y cómo el equipo de TaskBot traduce las speedruns asistidas por herramientas para crear la secuencia de entradas más rápida posible. También destaca los problemas principales en la preservación de grabaciones de videojuegos, incluyendo la subsamplificación cromática y las relaciones de aspecto estiradas en resoluciones pequeñas.

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í.

2. Desafíos en la preservación de grabaciones de juegos retro

Short description:

Entonces, quieres almacenar los registros en las resoluciones originales, sin estirar y evitar la interpolación bilineal. La compresión con pérdida y la corrupción intencional de CRT en los juegos retro plantean desafíos. Diferentes algoritmos, como Punto y Área, producen efectos distintos al escalar imágenes.

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.

3. Técnicas de Preservación de Grabaciones de Juegos Retro

Short description:

Los algoritmos de escalado bilineal y de área tienen efectos diferentes en las grabaciones de juegos de video. La simulación de CRT en RGBScaler.com reproduce las líneas de exploración y el efecto de la máscara de ranura. La charla concluye con una descripción general de las técnicas utilizadas en rgbscaler.com para preservar grabaciones nítidas de juegos de GameBoy de baja resolución, incluyendo el uso del algoritmo de área, videos codificados en AV1 y H265, y la capacidad de reproducir videos con efectos CRT.

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.

4. Codecs de Video y Configuración de WebGL

Short description:

Se utilizan los codecs de video AV1 y H.265 para admitir grabaciones sin pérdidas y un escalado adecuado de las grabaciones de arte de píxeles. AV1 es compatible con Firefox y Chrome en Android, mientras que H.265 permite reproducir videos en Safari y dispositivos iOS. Sin embargo, debido a problemas con iOS y Safari, no es posible tener una tercera opción de respaldo con una fuente H.264. Para ampliar el video en WebGL, se utiliza el algoritmo de escalado de área en lugar del bilineal. Se crea un lienzo personalizado con controles personalizados utilizando React, ya que los controles originales del reproductor de video no se pueden reutilizar. La interacción con el lienzo en React implica establecer un atributo de referencia a un callback y utilizar callbacks para la configuración de WebGL.

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.

5. Actualización de Textura WebGL y Lógica de Shader

Short description:

Si desactivas el diseño de arte para CRT, obtienes una escala de área pura. React gestiona el estado de los deslizadores y actualiza los uniformes de WebGL. Los efectos y los hooks personalizados manejan las dimensiones del video y la intensidad del efecto. La textura WebGL se actualiza utilizando un bucle de renderizado, capturando el fotograma del video y enviándolo a una textura. El hook useRef y el setAnimationFrame rastrean el fotograma de animación. Cancelar el renderizado y cancelar el fotograma de animación finalizan el bucle de renderizado cuando el video está en pausa. La lógica del shader recrea la máscara y las líneas de exploración basadas en la posición de los píxeles.

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.

6. WebGL y Controles del Reproductor de Video

Short description:

Y luego este puede estar en el espacio lineal. El efecto de área se porta desde el código fuente directo de Open Broadcaster Studio. Combinar eso con la máscara de ranura y las líneas de exploración en WebGL te brinda una experiencia de reproductor web de escalado preciso. La biblioteca React RGB Scaler permite resaltar la sintaxis en el vertex shader y el fragment shader, facilitando el desarrollo. Se utiliza una lógica simple de React para volver a implementar los controles del reproductor de video y controles personalizados para reproducir y pausar el lienzo. Se utiliza el escalado DPI para aprovechar al máximo la resolución del dispositivo. La pre-codificación de videos de alta resolución y su escalado hacia abajo desperdicia ancho de banda, mientras que el uso de la técnica propuesta reduce significativamente el tamaño de los videos.

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.

7. Valor del Sitio RGB Scaler

Short description:

El sitio RGB scaler demuestra el valor de mejorar la calidad de video mientras se utiliza significativamente menos ancho de banda que YouTube. Los datos sin pérdida para imágenes en 3D utilizando H264 o AV1 en H265 son de alrededor de cinco a 10 megabits por segundo, en comparación con 100 megabits por segundo para una mejora a 4k. Esta técnica proporciona una mayor calidad y un menor uso de datos para imágenes de juegos retro, especialmente para juegos 2D y Atari, y es aproximadamente cinco veces mejor para la era de N64.

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.