¿Qué es el encoding justo a tiempo?

El encoding justo a tiempo crea bajo demanda una variante multimedia solicitada en lugar de calcular de antemano cada variante de resolución, códec o calidad. Después, el resultado puede almacenarse en caché para solicitudes posteriores.

Un sistema justo a tiempo sitúa el codificador detrás de la URL de entrega. Una solicitud indica un origen y una receta; se consulta una caché para buscar un resultado almacenado y el encoding solo se ejecuta si no se encuentra, tras lo cual la salida se devuelve y se almacena para solicitudes posteriores. Esa caché puede ser una CDN delante del codificador, un almacenamiento que el propio servicio gestiona o ambos. Un codificador que no dispone de ninguno repite el trabajo en cada solicitud, y un resultado almacenado solo se reutiliza hasta que vence o se expulsa de la caché. Para las imágenes, la unidad de trabajo es una URL. Para el video, la unidad práctica es un segmento de un stream adaptativo, en lugar del archivo completo: un reproductor HLS solicita primero listas de reproducción, que el servicio genera sobre la marcha, y después solicita segmentos cortos, cada uno de los cuales se codifica la primera vez que se solicita. Solo se codifican las variantes y los intervalos de tiempo solicitados; los reproductores cargan segmentos por adelantado respecto de la posición de reproducción, por lo que pueden incluirse segmentos que nadie termina viendo. Mux, que lo llama transcodificación justo a tiempo, describe el envío en streaming de fotogramas desde el transcodificador antes de que se complete el resto del archivo.

¿El empaquetado justo a tiempo es lo mismo? No. El empaquetado justo a tiempo vuelve a empaquetar variantes que ya existen en el formato de streaming que solicita un reproductor. AWS Elemental MediaPackage lo describe como la creación de un manifiesto en un formato compatible con el dispositivo que lo solicita; su contenido de origen proviene de un codificador anterior para el video en vivo y, para el video bajo demanda, de archivos HLS o MP4 almacenados en Amazon S3. nginx-vod-module describe el reempaquetado sobre la marcha de archivos MP4 a DASH, HDS, HLS y MSS. Ninguno describe el encoding a una nueva resolución o tasa de bits, por lo que la escala de encoding debe seguir produciéndose de antemano. El encoding justo a tiempo también aplaza ese paso.
¿Qué costo tiene la primera solicitud y qué ocurre si llegan muchas a la vez? La primera solicitud de una salida debe esperar a que se recupere el archivo de origen y se realice el encoding; las solicitudes posteriores son aciertos de caché mientras el resultado permanezca almacenado en ella. La documentación de imgproxy señala que las CDN suelen eliminar el contenido al que se accede con poca frecuencia, por lo que una salida que se solicita rara vez puede codificarse más de una vez. Las primeras solicitudes concurrentes de la misma salida pueden iniciar un encoding cada una, a menos que la caché situada delante las agrupe en una sola o que el propio codificador comparta el trabajo en curso, como hace el servidor de imágenes imagor. La agrupación tiene condiciones: Cloudflare agrupa por centro de datos, proxy_cache_lock de NGINX está desactivado de forma predeterminada y, en Fastly, una respuesta que no puede almacenarse en caché hace que las solicitudes en cola se envíen al origen una tras otra.
¿Qué ocurre con la salida almacenada en caché cuando cambia la configuración de encoding? Nada de inmediato, salvo que el cambio altere la clave de caché. Un resultado almacenado se encuentra por su clave, normalmente formada por el origen, las opciones de procesamiento y el formato de salida, por lo que un cambio en un ajuste preestablecido del lado del servidor, la calidad predeterminada o una marca de agua que no se refleje en la solicitud deja la salida anterior en su lugar hasta que vence o se invalida. imgproxy documenta una opción de URL cachebuster precisamente para este caso y señala que su caché interna no tiene invalidación manual, sino únicamente el vencimiento establecido en el almacenamiento que utiliza. Incluir una versión en la URL cuando cambia una receta asigna de inmediato una nueva clave a la nueva salida.
¿Qué debería ocurrir cuando falla un encoding? La respuesta de error necesita su propia política de caché. Si lleva el tiempo de vida de un resultado satisfactorio, un fallo transitorio persiste: un usuario de imgproxy informó de una respuesta 504 enviada con un encabezado Cache-Control de un año y almacenada por una caché NGINX situada más adelante. Si los errores nunca se almacenan en caché, cada solicitud de un archivo de origen defectuoso repite el fallo costoso. Sin encabezados de caché explícitos, HTTP permite que una caché almacene y reutilice una respuesta 404, que puede almacenarse en caché de forma heurística, pero no una respuesta 500, 503 o 504. Las directivas de Cache-Control cambian esto en uno u otro sentido: max-age o public permite almacenar un error de ese tipo, y no-store prohíbe almacenar cualquier respuesta.

El encoding justo a tiempo resulta útil cuando no puedes predecir qué variantes o qué partes de un archivo se solicitarán: grandes archivos de contenido y subidas de usuarios cuyo material rara vez se ve en su mayoría, o tamaños de imagen que dependen de diseños que aún no has creado. Los procesos de encoding que nadie solicita nunca se ejecutan. Para el material que rara vez se solicita, el tiempo que un resultado permanece en caché determina con qué frecuencia una solicitud repetida vuelve a pagar el costo del encoding. En cambio, realiza el encoding de antemano cuando todas las salidas deban estar listas antes de la publicación, cuando alguien deba revisarlas primero o cuando la primera solicitud deba ser tan rápida como todas las posteriores. Una escala fija de variantes no es, por sí sola, un motivo para realizar el encoding de antemano: un codificador justo a tiempo puede servir variantes predefinidas y aun así omitir los segmentos que nadie solicita.

Transloadit ofrece encoding justo a tiempo a través de su Smart CDN. Para video, el Robot /video/ondemand genera listas de reproducción y segmentos HLS bajo demanda: un reproductor solicita la lista de reproducción multivariante desde una URL de tlcdn.com, cada segmento se codifica la primera vez que se solicita y el Smart CDN almacena en caché las listas de reproducción y los segmentos para espectadores posteriores. Para imágenes y otros archivos, una URL de Smart CDN ejecuta un Template cuando no encuentra el resultado en caché y sirve el resultado almacenado en caché hasta que vence.

La documentación de /video/ondemand describe la salida HLS. El Robot /file/serve establece cuánto tiempo se almacenan los resultados en caché: de forma predeterminada, indica a las CDN que conserven un resultado durante 24 horas y a los navegadores durante 72 horas, y cache_duration modifica ambos plazos. Cuando las URL de las listas de reproducción se firman con sign_urls_for, los plazos de vencimiento más cortos reducen la reutilización de la caché y pueden aumentar la regeneración de segmentos. Las páginas enlazadas no indican qué ocurre con los resultados que ya están en caché cuando se edita un Template, ni qué recibe un reproductor cuando falla el encoding de un segmento, así que prueba ambas situaciones antes de depender de ese comportamiento.

Explora las capacidades de entrega de Transloadit

¿Qué es el encoding justo a tiempo?

Cómo funciona el encoding justo a tiempo

Datos clave

Cuándo es importante el encoding justo a tiempo

Cómo ayuda Transloadit con el encoding justo a tiempo

Fuentes

Convierte tus conocimientos sobre multimedia en un pipeline funcional