Qu’est-ce que l’encodage juste à temps ?

L’encodage juste à temps crée le rendu multimédia demandé au moment où il est nécessaire, au lieu de précalculer toutes les variantes de résolution, de codec ou de qualité. Le résultat peut ensuite être mis en cache pour les requêtes ultérieures.

Un système d’encodage juste à temps place l’encodeur derrière l’URL de diffusion. Une requête désigne une source et une recette de traitement ; le système cherche un résultat stocké dans un cache et ne lance l’encodage que si ce résultat est absent, puis renvoie et stocke le résultat pour les requêtes ultérieures. Ce cache est un CDN placé devant l’encodeur, un stockage géré par le service lui-même, ou les deux. Un encodeur qui ne dispose ni de l’un ni de l’autre répète le travail à chaque requête, et un résultat stocké n’est réutilisé que jusqu’à son expiration ou son éviction. Pour les images, l’unité de travail est une URL. Pour la vidéo, l’unité pratique est un segment de flux adaptatif plutôt que le fichier entier : un lecteur HLS demande d’abord des listes de lecture, que le service génère à la volée, puis de courts segments, chacun étant encodé lors de sa première demande. Seuls les rendus et les plages temporelles demandés sont encodés ; les lecteurs chargent les segments en avance sur la position de lecture, ce qui peut donc inclure des segments que personne ne regardera finalement. Mux, qui appelle cela le transcodage juste à temps, décrit la diffusion des images depuis le transcodeur avant que le reste du fichier soit terminé.

Le conditionnement juste à temps est-il la même chose ? Non. Le conditionnement juste à temps réencapsule des rendus existants dans le format de streaming demandé par un lecteur. AWS Elemental MediaPackage le décrit comme la création d’un manifeste dans un format compatible avec l’appareil demandeur ; son contenu source provient d’un encodeur en amont pour la vidéo en direct et, pour la vidéo à la demande, de fichiers HLS ou MP4 stockés dans Amazon S3. Le nginx-vod-module décrit la réencapsulation à la volée de fichiers MP4 en DASH, HDS, HLS et MSS. Aucun des deux ne décrit un encodage vers une nouvelle résolution ou un nouveau débit ; l’échelle de rendus doit donc toujours être produite à l’avance. L’encodage juste à temps diffère aussi cette étape.
Quel est le coût de la première requête et que se passe-t-il si plusieurs arrivent en même temps ? La première requête visant un résultat attend la récupération de la source et l’encodage ; les requêtes ultérieures trouvent le résultat en cache tant qu’il y reste. La documentation d’imgproxy précise que les CDN suppriment généralement les contenus rarement consultés ; un résultat rarement demandé peut donc être encodé plusieurs fois. Des premières requêtes simultanées visant le même résultat peuvent chacune lancer un encodage, sauf si le cache placé devant les regroupe en une seule ou si l’encodeur partage lui-même le traitement en cours, comme le fait le serveur d’images imagor. Ce regroupement est soumis à des conditions : Cloudflare regroupe les requêtes par centre de données, l’option proxy_cache_lock de NGINX est désactivée par défaut, et sur Fastly, une réponse qui ne peut pas être mise en cache entraîne l’envoi des requêtes en attente à l’origine l’une après l’autre.
Que devient le résultat en cache lorsque les paramètres d’encodage changent ? Rien dans l’immédiat, sauf si la modification change la clé de cache. Un résultat stocké est retrouvé grâce à sa clé, généralement composée de la source, des options de traitement et du format de sortie. Ainsi, la modification d’un préréglage côté serveur, de la qualité par défaut ou d’un filigrane, si elle n’est pas reflétée dans la requête, laisse l’ancien résultat en place jusqu’à son expiration ou son invalidation. imgproxy documente une option d’URL cachebuster précisément pour ce cas et précise que son cache interne ne permet pas d’invalidation manuelle, mais uniquement une expiration définie sur le stockage sous-jacent. Inclure une version dans l’URL lorsqu’une recette de traitement change attribue immédiatement une nouvelle clé au nouveau résultat.
Que doit-il se passer lorsqu’un encodage échoue ? La réponse d’erreur doit avoir sa propre politique de cache. Si elle indique la durée de conservation d’un résultat réussi, une défaillance transitoire persiste : un utilisateur d’imgproxy a signalé une réponse 504 envoyée avec un en-tête Cache-Control indiquant une durée d’un an et stockée par un cache NGINX en aval. Si les erreurs ne sont jamais mises en cache, chaque requête visant une source défectueuse répète cet échec coûteux. Sans en-têtes de cache explicites, HTTP permet à un cache de stocker et de réutiliser une réponse 404, qui peut être mise en cache de manière heuristique, mais pas une réponse 500, 503 ou 504. Les directives Cache-Control modifient ce comportement dans un sens comme dans l’autre : max-age ou public permet de stocker une telle erreur, et no-store interdit de stocker toute réponse.

L’encodage juste à temps est avantageux lorsque vous ne pouvez pas prévoir quels rendus ou quelles parties d’un fichier seront demandés : grandes archives et téléversements d’utilisateurs dont la majorité des contenus sont rarement regardés, ou dimensions d’image dépendant de mises en page que vous n’avez pas encore créées. Les encodages que personne ne demande ne sont jamais exécutés. Pour les contenus rarement demandés, la durée de conservation d’un résultat en cache détermine à quelle fréquence une nouvelle requête entraîne à nouveau le coût de l’encodage. Préencodez plutôt les contenus lorsque chaque résultat doit être prêt avant publication, lorsque quelqu’un doit d’abord le vérifier ou lorsque la première requête doit être aussi rapide que les suivantes. Une échelle de rendus fixe n’est pas en soi une raison de préencoder : un encodeur juste à temps peut fournir des rendus prédéfinis tout en évitant les segments que personne ne demande.

Transloadit propose l’encodage juste à temps via son Smart CDN. Pour la vidéo, le Robot /video/ondemand génère des listes de lecture et des segments HLS à la demande : un lecteur demande la liste de lecture multivariante à une URL tlcdn.com, chaque segment est encodé lors de sa première demande, et le Smart CDN met les listes de lecture et les segments en cache pour les spectateurs suivants. Pour les images et les autres fichiers, une URL du Smart CDN exécute un Template en l’absence de résultat en cache et diffuse le résultat mis en cache jusqu’à son expiration.

La documentation relative à /video/ondemand décrit une sortie HLS. Le Robot /file/serve définit la durée de mise en cache des résultats : par défaut, il indique aux CDN de conserver un résultat pendant 24 heures et aux navigateurs pendant 72 heures, et cache_duration modifie ces deux durées. Lorsque les URL des listes de lecture sont signées avec sign_urls_for, des délais d’expiration plus courts réduisent la réutilisation du cache et peuvent augmenter la fréquence de régénération des segments. Les pages liées ne précisent pas ce que deviennent les résultats déjà en cache lorsqu’un Template est modifié, ni ce qu’un lecteur reçoit lorsque l’encodage d’un segment échoue ; testez donc ces deux cas avant de vous y fier.

Explorer les capacités de diffusion de Transloadit

Qu’est-ce que l’encodage juste à temps ?

Fonctionnement de l’encodage juste à temps

Points clés

Quand l’encodage juste à temps est important

Comment Transloadit facilite l’encodage juste à temps

Références

Transformer vos connaissances sur les médias en une chaîne de traitement opérationnelle