Video Summary and Transcription
Esta charla discute los desafíos de la edición de video en el navegador y las limitaciones de las herramientas existentes. Explora técnicas de compresión de imágenes, incluyendo la transformada de Fourier y la codificación de Huffman, para reducir el tamaño de los archivos. Se explica el códec de video y el proceso de decodificación de cuadros, destacando la importancia de los cuadros clave y los cuadros delta. Se identifica el cuello de botella del rendimiento como el códec, y se enfatiza la necesidad de hardware especializado para una edición de video eficiente. La charla concluye con un llamado a crear una API simplificada para la edición de video en el navegador y el potencial de la edición de video impulsada por IA.
1. Introducción a la edición de video en el navegador
Hola a todos. Hoy, quiero hablar sobre la edición de video en el navegador. Pasé mucho tiempo editando videos durante la pandemia. Sin embargo, me di cuenta de que las herramientas existentes no tenían los avances de IA que necesitaba. Quería eliminar la pantalla verde y las sombras, y cortar en función de las palabras habladas. Por otro lado, vi desarrollos emocionantes en JavaScript, como WebCodecs, TensorFlow.js y Whisper. Esta charla explicará por qué no pude lograr completamente un buen editor de video impulsado por IA. Comencemos pensando en hacer un video.
Hola a todos. Mi nombre es Christophe Archido, también conocido como Vegeux en Internet. Y he hecho algunas cosas para la React comunidad. Co-creé React Native, Prettier, Excalibur, CSS en JS, pero hoy quiero hablar sobre algo diferente. Quiero hablar sobre la edición de video en el navegador.
Entonces, durante la pandemia, pasé mucho tiempo editando video. E incluso pensé que tal vez debería convertirme en un YouTuber a tiempo completo. Pero luego me di cuenta de que con este número de vistas, probablemente debería mantener mi trabajo como ingeniero de software un poco más de tiempo.
Entonces, ¿qué significa editar videos? Así que usé una herramienta llamada Final Cut Pro. Y sentí que se construyó hace muchos, muchos años y no tenía todos los avances de AI que hemos visto recientemente. Entonces, por ejemplo, compré una pantalla verde de $20. Y necesito seleccionar el color verde y el rango para eliminarlo. Y como pueden ver, hay algunas sombras detrás de mí en la imagen. Y no se eliminó correctamente. Luego, para cortar, quiero saber qué estoy diciendo realmente para saber qué parte debería estar cortando. Pero solo obtuve las ondas de sonido y no las palabras reales que se hablaron. Por otro lado, estaba mirando el JavaScript, como las noticias del navegador, y vi muchas cosas súper emocionantes sucediendo. Entonces, podemos comenzar a hacer codificación y decodificación con WebCodecs. TensorFlow.js te permite eliminar el fondo del video. Y luego, Whisper te permite convertir lo que estoy diciendo en palabras reales. Entonces, aparentemente teníamos todos los bloques de construcción para poder hacer un muy buen editor de video impulsado por AI, pero desafortunadamente, no pude llegar hasta el final. Y esta charla va a ser la historia de por qué.
Entonces, generalmente cuando me adentro en un nuevo producto como este, hay algunas cosas que creo que son ciertas y voy a usar para basar todas las cosas que estoy haciendo. Pero hubo tres cosas en este caso que no eran ciertas. Entonces, la primera es que el tiempo solo avanza. La segunda es que cuando codificas un fotograma, obtienes un fotograma de vuelta. Y finalmente, que WASM es más rápido que JavaScript para la decodificación de video. Entonces, si quieres saber por qué esto no es cierto, abróchate el cinturón. Vamos a ello. Entonces, comencemos pensando en hacer un video.
2. API de edición de video y compresión de imágenes
Desafortunadamente, la API deseada para la edición de video en el navegador no es posible debido a los grandes tamaños de archivo involucrados. Una sola imagen de mil por mil píxeles ya puede tener alrededor de cuatro megabytes de tamaño. Con 60 fotogramas por segundo, un video de un segundo sería de alrededor de 200 megabytes. Esto es demasiado grande para los navegadores y computadoras actuales. Sin embargo, se han desarrollado técnicas de compresión de imágenes para abordar este problema, que se discutirán en los siguientes minutos.
Y desafortunadamente no puedo estar aquí en persona hoy, así que lo que decidí hacer fue traer un poco de la soleada California a Ámsterdam. Y para esto puse una palmera en todas las imágenes. Entonces, en este caso, tenemos la cumbre de React en el fondo y luego moviéndonos al primer plano y la palmera desvaneciéndose. Entonces, ¿cuál sería la API que esperaría poder hacer eso? Así que inicialmente quería una API de carga de video. Que toma una ruta de archivo y me devuelve una lista de imágenes. Y luego voy a modificar las imágenes, eliminar el fondo, como cortar y pegar y un montón de cosas. Y luego como un guardar video que tomaría la ruta del archivo y renderizaría. Y como una lista de imágenes y como realmente guardar el video.
Entonces, desafortunadamente, esta API no puede existir. Veamos por qué. Así que vamos a ver una imagen de todo este video. Ni demasiado grande, ni demasiado pequeña. Como una imagen de mil por mil. ¿Y cuán grande es en realidad para representar esto? Va a ser como mil por mil píxeles. Alrededor de un megabyte. Y luego hay rojo, verde y azul. Y entonces estamos alrededor de cuatro megabytes de tamaño. Y esto es solo para una imagen. Ahora, si quieres como 60 fps, como un segundo, vas a estar en alrededor de 200 megabytes por cada segundo. Así que esta charla ahora mismo es de unos 20 minutos. Así que esto va a ser grande. Y esto en realidad va a ser demasiado grande para el navegador o cualquier computadora en este momento. ¿Y qué hacemos? Afortunadamente, muchas personas muy inteligentes han trabajado en esto durante años. Y lo que construyeron es una máquina de encogimiento. Bueno, no exactamente. Lo que la gente ha estado haciendo es la compresión de imágenes. Y entonces voy a hablar durante los próximos minutos sobre diferentes tipos de compresión de imágenes. Y no porque lo encuentre interesante, que lo hago, sino porque en realidad tienen un gran factor en la API real utilizada para la codificación de video. Así que veamos las ideas principales en torno a la codificación de video. Lo siento, sobre la compresión de imágenes.
3. Técnicas de Compresión de Imágenes
En los fotogramas de video con solo dos colores, podemos usar la codificación de longitud de ejecución para reducir el tamaño. Sin embargo, esta técnica no es efectiva para imágenes con variación de colores de píxeles. Exploraremos otras técnicas para abordar este problema.
Entonces, si miras este fotograma, una cosa que podemos ver es que solo se usan dos colores y hay muchos píxeles blancos y oscuros. Y en lugar de mostrar siete píxeles oscuros seguidos con rojo, verde, azul, rojo, verde, azul, rojo, verde, azul, lo que podemos hacer es comenzar a escribir un byte, que es un número del píxel, y luego el rojo, verde, azul una vez, y luego básicamente podemos repetirlo así. Y esta es una técnica llamada codificación de longitud de ejecución. Ahora, esta técnica en sí es muy útil para imágenes con solo dos colores, pero si tú tomas una foto con tu cámara, nunca vas a ver dos píxeles uno al lado del otro con el mismo color exacto. Y vamos a ver a continuación cómo ayudar con esto, pero ten en cuenta que este es un bloque de construcción para comprimir imágenes que se va a utilizar en el pipeline.
4. Técnicas de Compresión de Imágenes Continuadas
Podemos usar una transformación de Fourier para descomponer la imagen en funciones sinusoidales y reducir la información necesaria para codificarla. Otra técnica es la codificación de Huffman, que remapea patrones de 0s y 1s para comprimir la imagen. Estos bloques de construcción, junto con otros, permiten una reducción de 10 veces en el tamaño de la imagen. Sin embargo, para los videos, podemos mejorar aún más la compresión codificando solo las diferencias entre fotogramas consecutivos y prediciendo el siguiente fotograma.
Entonces, la otra estrategia de la que voy a hablar, necesitas tener algo de imaginación para esto. En este caso, vamos a pensar en la imagen no como una serie de píxeles sino como una función continua. Y una de las cosas que podemos hacer con una función continua es ejecutar una transformación de Fourier en la parte superior de esto, que va a descomponer esta función continua en una suma infinita de funciones sinusoidales como seno y coseno con alguna variación. ¿Por qué querrías eso? ¿Cómo es útil? Entonces, lo que puedes ver en la ilustración son las primeras funciones sinusoidales, que en realidad terminan siendo muy cercanas a la función final y luego cuanto más bajas en esas funciones sinusoidales menos información tienen.
En la práctica, si solo mantienes las primeras y las vuelves a codificar, vas a obtener una imagen muy cercana pero pierdes muchos de los detalles que quizás no puedas percibir. Ahora, cada una de esas está tomando aproximadamente la misma cantidad de bits para codificar, por lo que al hacer esto puedes reducir la información que tienes que codificar para comprimir la imagen. Y la tercera técnica de la que voy a hablar... También necesitas pensar en la imagen de una manera diferente, en este caso una serie de 0s y 1s. Y entonces una de las cosas que podemos empezar a observar es que algunos patrones están emergiendo.
Entonces, por ejemplo, la secuencia 0 1 0 1 está ahí 15 veces. Luego la secuencia 1 1 0 solo está ahí como 7 veces y luego sigues y en algún punto algunas de ellas solo van a estar ahí una vez. Y la idea detrás de la compresión es que puedes hacer un remapeo. Puedes remapear 0 1 0 1 al bit 0, luego puedes remapear 1 1 0 a los 2 bits 1 0, y luego sigues haciendo y en algún punto, porque mapeaste un montón de cosas a cosas más pequeñas algunas cosas necesitarían ser mapeadas a cosas más grandes. Pero si miras todas las secuencias de 0s y 1s, se va a comprimir usando esta técnica si también añades la tabla de mapeo. Esto se llama codificación de Huffman. Entonces, estos son como tres bloques de construcción para comprimir la imagen. ¿Y cuál es el resultado de esto? Somos capaces de obtener una reducción de 10 veces en el tamaño de la imagen. Entonces, pasando de como 4 MBs, estamos como en 400K. Y el nombre de este paso es compresión de imagen. Y las compresiones de imagen más populares que hay son como JPEG, WEBP, PNG. Y entonces esto es como, usan todos estos bloques de construcción y algunos más para comprimir la imagen. Así que hemos hecho un progreso masivo para hacer que la imagen sea más pequeña, pero todavía es como 20 MBs por segundo para nuestro video. Así que esto es como todavía demasiado. ¿Qué más podemos hacer? Entonces, para esto, podemos pensar en nuestro video como una serie de imágenes. Pero ahora lo que puedes ver es que todas las imágenes una al lado de la otra son en realidad muy, muy parecidas entre sí. Y entonces probablemente haya algo que podamos hacer al respecto. Entonces, la primera idea es que solo vamos a hacer una diferencia de la imagen anterior y la imagen posterior. Y codificar solo la diferencia usando esas estrategias anteriores. Y esto está funcionando y esto está dando mejores resultados, pero podemos hacerlo aún mejor. Lo que podemos hacer es empezar a predecir cómo va a ser la próxima imagen.
5. Codec de Video y Decodificación de Fotogramas
El codec de video reduce drásticamente el tamaño de los fotogramas. Hay dos tipos de fotogramas: fotogramas clave y fotogramas delta. Para decodificar el video, se requiere una API con estado y los fotogramas deben enviarse en un orden específico. Los fotogramas bidireccionales (B-frames) optimizan la codificación de video al decodificar fotogramas en ambas direcciones. Esto introduce dos nociones de tiempo: tiempo de presentación y marca de tiempo de decodificación. La API debería incluir una API de carga de video y una API de decodificador.
Y en este caso, la palmera va desde la parte superior izquierda hasta la inferior derecha. Y así puedes empezar a predecir dónde va a estar la próxima imagen y luego hacer la delta basada en esta predicción. Y este paso se llama un video codec. Y los video codecs más populares son H.264 y AVC, que son lo mismo pero con un nombre diferente como JavaScript y Xamarin. Y también está AV1, VP8, VP9.
Así que este video codec es capaz de nuevo de reducir drásticamente el tamaño. Así que en este caso, así es como se ve nuestra configuración. Así que ahora tenemos dos tipos de fotogramas. Tenemos fotogramas clave, así que en este caso, el primer fotograma, que utiliza algo como JPEG para comprimirlo, y luego tenemos fotogramas delta. Así que en este caso, como cada uno en esta imagen.
Y ahora, para decodificar el video, ya no es, oh, solo dame una imagen y puedo hacerlo. Ahora necesitas empezar con el fotograma clave. Y luego, para decodificar el segundo, necesitas haber decodificado el fotograma clave, hacer la predicción de dónde va a estar a continuación, y luego hacer la delta para decodificarlo. Así que ahora estamos viendo que necesitamos una API con estado y en un orden específico. Pero esto es solo una parte de la imagen, porque la gente que hace la codificación y compresión de video quería hacerlo aún mejor. Una cosa que se dieron cuenta es que puedes hacer esta optimización hacia adelante. Pero también puedes hacerlo hacia atrás. Así que puedes empezar desde el final, hacer la predicción, la codificación, y luego empezar a mirar en qué dirección obtenemos los mayores ahorros. Y tomar el que en realidad va a ser el más pequeño en general. Y aquí es donde entra la noción de fotogramas bidireccionales o B-frames. Así que en este caso, el fotograma número 5 es un B-frame, lo que significa que para decodificarlo, necesitas decodificar el número 4 y el número 6. Y también para decodificar el número 6, necesitas hacer como el 7, y 7 necesitas 8 y 8 necesitas 9, y lo mismo en el otro sentido. Y así que ahora lo que estás viendo es que para decodificar la secuencia de video en orden, necesitas enviar todos los fotogramas en un orden diferente. Y aquí es donde tenemos dos nociones de tiempo. Así que tenemos el tiempo de presentación, que es el que esperas ver en la duración de la película, y luego el segundo es la marca de tiempo de decodificación. Y así que esta es la marca de tiempo en la que necesitas enviar los fotogramas para ser decodificados en el orden correcto. Y así es donde tenemos nuestra primera, en realidad no hay verdad, donde el tiempo solo avanza. Así que ahora que hemos visto la primera ruptura de cosas, volvamos a la API, en realidad la API real. Así que en este caso, necesitamos tener algún tipo de API de carga de video para darnos todos los fotogramas. Y luego queremos una API de decodificador.
6. Decodificación de Video y Rendimiento
Los códecs web proporcionan un decodificador de video con opciones, incluyendo una devolución de llamada en fotogramas decodificados. La decodificación de fotogramas puede no devolver los fotogramas en el mismo orden en que fueron enviados. La API de carga de video requiere almacenar metadatos, como el tiempo de fotograma, tipos, marcas de tiempo y dependencias. Los contenedores de video como mp4, move, avi y mkv contienen los fotogramas para el códec. El cuello de botella del rendimiento es el códec, que maneja la compresión de imágenes, descompresión, predicciones y codificaciones.
Y en este caso, los códecs web, como el navegador nos proporciona un decodificador de video con un montón de opciones, incluyendo una que es una devolución de llamada en fotograma decodificado. Y ahora necesitas hacer decoder.decode, enviar como el primer fotograma, y luego va a procesar, y en algún momento nos va a dar una devolución de llamada con la primera imagen. Y luego lo hacemos con el número dos, número tres, número cuatro, y los estamos obteniendo en orden. Pero ahora, ¿qué pasa con nuestros fotogramas B, así que ahora lo que necesitamos hacer es enviar el fotograma número nueve, y luego el fotograma número ocho, y luego el fotograma siete y seis. Pero nuestra devolución de llamada no va a ser llamada. Es como si nada sucediera, pero en la práctica, un montón de cosas están sucediendo detrás de la escena. Y sólo cuando enviamos el fotograma número cinco, ahora va a hacer toda la cadena de nuevo y va a llamar a todos nuestros fotogramas en el orden correcto para que podamos usar. Y aquí es donde la verdad número dos es una mentira. Así que si estás decodificando un fotograma, no estás obteniendo un fotograma de vuelta. Así que en la práctica, puedes obtener como cero o puedes obtener como cinco basado en cómo se ha hecho la codificación. Y esto es muy desconcertante porque todas las APIs que puedo pensar, incluso la API asincrónica cuando llamas a algo te lo va a devolver después de algún tiempo, pero nunca es como si estuvieras obteniendo uno o diez o como cero, y de una manera muy impredecible. Así que ahora que hemos visto otra verdad, vamos aún más profundo. Así que pensemos en esta API de carga de video de la que hablé. Entonces, ¿cómo codificarías toda esta información? Así que ahora hay un montón de metadatos que necesitamos. Así que necesitamos tener como, hey, ¿cuánto tiempo es un fotograma? ¿Cuál es la lista de fotogramas? ¿Cuáles son nuestros tipos? ¿Cuáles son las marcas de tiempo? ¿Cuáles son nuestras dependencias entre ellos? Así que hay un montón de metadatos que necesitan ser almacenados. Y así que si lo hiciéramos hoy, probablemente lo implementaríamos en JSON. Pero todos esos cinco formatos han sido escritos hace 20 años. Y así que todos están en binario, pero la idea es la misma. Entonces, ¿cómo se llama este paso? Entonces, ¿cómo se llama esta cosa? Esto se llama un contenedor de video. Y así que en la práctica, los cuatro más conocidos son el mp4, move, avi y mkv. Y todos ellos usan diferentes codificaciones y diferentes formas de representar esto, pero todos tienen información muy similar que se trata de un contenedor para luego llamar al códec. Y este paso de leer estos formatos de archivo y luego enviar todos los fotogramas en el orden correcto al códec se llama demuxing. Así que ahora se llama demuxing. Así que ahora hablemos un poco sobre el rendimiento. Entonces, ¿qué toma tiempo en todo esto? Así que en la práctica, el códec es la parte que toma más tiempo. Y para refrescar tu mente, el códec está haciendo toda la compresión de imágenes, descompresión, todas las predicciones, todas las delta, todas estas codificaciones. Y una de las formas de pensar en ello es simplemente mirar el tamaño de las cosas. Así que los datos binarios son como en las decenas a cientos de kilobytes. Pero entonces los metadatos reales para cada fotograma son como decenas de caracteres. Y así puedes ver un cambio muy grande.
7. Desafíos de la edición de video y llamado a la acción
La edición de video en el navegador es compleja y consume mucho tiempo, requiriendo hardware especializado para el rendimiento. WebCodecs permite el uso de JavaScript para aprovechar las funcionalidades aceleradas por hardware. Sin embargo, el uso de WebAssembly (Wasm) para la lectura y decodificación de archivos plantea desafíos debido a la copia de memoria. Wasm no es más rápido que el JavaScript puro para la decodificación de video, pero puede ser útil para la reutilización de código. Aunque aún no está disponible un editor de video completamente funcional con capacidades de IA, es posible decodificar y volver a codificar archivos de video en el navegador con buen rendimiento. El llamado a la acción es crear una API tipo jQuery para la edición de video en el navegador, simplificando el proceso y habilitando la edición de video impulsada por IA.
Y esto es tan consumidor de tiempo y complicado y necesita tener tanto performance que ahora hay unidades de hardware especializadas junto a la CPU o la GPU que está realizando todas las operaciones que mencioné, como la Transformada Rápida de Fourier, la codificación Huffman, y todas esas cosas en el hardware. Y la razón por la que está en el hardware es porque simplemente hacerlo en la CPU normalmente, incluso con el code C++ más escrito a mano, no era lo suficientemente rápido. Y así que ahora si quieres usar Wasm, ahora tendrías que no sólo tener algo no tan rápido porque se está ejecutando en la CPU, pero con algo de sobrecarga para Wasm. Y así hacer esto de esa manera va a ser más lento. Y aquí es donde WebCodecs es muy emocionante es que ahora somos capaces de usar una API de JavaScript, enviar todos estos datos binarios y la API de WebCodec va a estar usando todas esas funcionalidades aceleradas por hardware. Así que esto es emocionante. Ahora, esto es sólo una parte de la ecuación. La segunda parte es que necesitamos hacer para leer este archivo, este archivo binario, como hacer este demuxing. ¿Podríamos usar Wasm para ello? Así que de nuevo, la historia es un poco más complicada. Así es como funciona Wasm, crea un nuevo montón de memoria, como un espacio de memoria. Y para code en él y para que haga su trabajo, necesitas copiar toda la información a este nuevo espacio, luego hacer su trabajo y luego copiarlo y luego devolvértelo. Y aquí estamos hablando de cientos de kilobytes, como megabytes de información, y hacer una copia para no hacer mucho trabajo para decodificar esto, y luego copiarlo de nuevo y luego enviarlo de vuelta a la API web correcta. Y así hacer esta copia en realidad anula cualquiera de las victorias que puedas tener al usar Wasm, que es más rápido. Así es donde nuestra tercera verdad se convierte en una mentira, donde Wasm no es más rápido que usar JavaScript puro para la decodificación de video. Ahora una advertencia que voy a decir es en la práctica para el de-muxing no es parte de la API de web codec. No es parte del navegador. Así que necesitas hacerlo en lente de usuario. Y hay tantas APIs de C++ para de-muxing que se han escrito a lo largo de los años. Y así para la reutilización de code es en realidad una forma legítima de usar Wasm para esto. Pero en realidad no es por razones de performance. Así que ahora que hemos desacreditado estos tres mitos y ¿dónde estamos? Y así en la práctica desearía terminar la charla con, hey, puedes usar este editor de video con todas sus funcionalidades. Aún no estoy allí. Así que lo que he podido hacer es conseguir, decodificar un archivo de video entero y volver a codificar sin hacer nada. Y en el navegador. La buena noticia es que, uno, es posible y funciona. Y la segunda es que es realmente rápido. Así que porque estamos usando las características aceleradas por hardware, es tan rápido como usar Final Cut Pro en el navegador. Así que el rendimiento está ahí. La capacidad está ahí. Pero el problema es que hacerlo requiere cientos de líneas de code en las trincheras que es muy difícil de debug y necesita entender todas las cosas de las que he hablado hasta ahora. Y así es donde mi llamado a la acción para cada uno de ustedes es, necesitamos tener un jQuery de edición de video en el navegador. Necesitamos limpiar la API y empaquetarla de una manera para poder hacer un editor de video con AI posible. Entonces, ¿vas a ser tú el que lo construya? Este es mi llamado a la acción. Gracias, que tengas un buen día.
Comments