Convertir MOV en WebP

Le décodeur prend l’image à l’instant demandé, l’encodeur l’écrit en WebP avec perte à la qualité par défaut de 82. Le résultat est une image fixe, pas une séquence animée, et un MOV qui dure une heure donne la même sortie qu’un MOV qui dure dix secondes : une seule image, à l’instant indiqué.

WebP a un mode animé qui permet de stocker des séquences, et le pipeline du navigateur le sait faire, mais ce n’est pas ce que cette conversion produit. Pour une image animée tirée d’une vidéo, il faut un outil de GIF animé ou de WebP animé, et la page MOV → GIF en est un autre exemple. Cette page-ci est strictement pour une image fixe en sortie.

Le code de l’encodeur fixe la qualité à 82 pour WebP, comme pour JPEG, AVIF et JXL. C’est le réglage commun à toute la chaîne d’écriture des images avec perte, et il est mesuré : à 82, la perte est invisible à distance normale de lecture sur un écran calibré, et la taille reste raisonnable. À 95 le fichier est beaucoup plus gros pour un gain presque imperceptible.

Pour un original d’archive, 82 n’est pas la bonne valeur : la sortie aura perdu quelque chose, et ce quelque chose ne se récupère pas. Pour une vignette de site web, 82 est même trop élevé, et un passage à 60 coupe la taille de moitié sans rien retirer à l’œil. La conversion ne propose pas de curseur de qualité sur cette paire, et la sortie est toujours à 82 ; pour un autre réglage, convertir la même image en JPEG ou AVIF.

WebP a deux modes : avec perte à base de VP8, et sans perte à base de prédiction par pixel. Le pipeline du navigateur ne demande que le mode avec perte, parce que la sortie est déjà un décodage de pixels et que l’option sans perte ne s’imposerait que si la cible exigeait une fidélité au bit près. Pour un MOV, la source est elle-même avec perte, et le mode sans perte ne ferait que préserver les artéfacts du codec vidéo avec une fidélité parfaite.

Le mode sans perte reste accessible par un autre chemin : extraire l’image en PNG avec MOV → PNG, qui passe par un encodeur sans perte, et c’est la bonne route pour un usage en archive. WebP est sur cette page comme format de diffusion et de web, et c’est dans ce rôle qu’il sert.

Le contrôle demande un nombre en secondes avec un pas d’un dixième, et l’image la plus proche est retournée. Sur une vidéo à 30 images par seconde, c’est presque toujours l’image exacte ; sur une vidéo à 23,976 images par seconde, c’est l’une des deux images qui entourent l’instant, et la différence est invisible.

Pour un usage en archive ou en vignette, la précision à la seconde est plus qu’il n’en faut. Pour un travail d’incrustation ou de comparaison image par image, le moment exact est calculé à partir de la cadence de la vidéo, et il vaut mieux prélever les images soi-même avec FFmpeg à la cadence native. Cette conversion est faite pour la commodité, pas pour la précision d’imageur.

Un iPhone enregistre des images en paysage et y attache une note de rotation. Un MOV issu d’un iPhone en portait une, et le décodeur l’applique : un clip en portrait sort en portrait dans le WebP, à 1 080 par 1 920 pixels si la source était en 1 080p vertical. C’est cohérent avec ce que ferait un lecteur vidéo.

Un MOV dont la note de rotation a été retirée par un éditeur sort avec les pixels bruts, ce qui peut donner une image couchée sur le côté. Si la cible lit strictement les pixels et ignore les métadonnées, vérifiez sur un cas avant d’alimenter une chaîne. Pour un MOV du quotidien, ce cas est rare.

Le MOV n’a pas de canal alpha : la vidéo est toujours opaque, par construction, et le décodage produit des pixels RGB sans alpha. Le WebP en sortie est donc lui aussi sans alpha, et l’éventuel canal transparent que WebP sait porter n’est pas utilisé. C’est cohérent avec la source, et c’est le bon réglage par défaut.

Si la cible attend une image avec un canal de découpe, ajouter un masque dans un éditeur après la conversion est la route normale. Aucune conversion ne fabrique de l’alpha à partir d’une source qui n’en a pas, parce qu’il n’y a rien dans l’image qui dise quelle zone est censée être transparente.

Un instant au-delà de la durée réelle du MOV produit une erreur qui nomme la durée : « le fichier ne dure que 14,3 secondes ». C’est un cas rare parce que la conversion refuse aussi les valeurs négatives, mais cela arrive quand l’instant est estimé plutôt que mesuré, et un coup d’œil dans un lecteur avant la conversion le prévient.

Pour un MOV long, prélever l’instant en secondes une fois dans un viewer, plutôt que d’estimer. Le MOV d’une heure qui a un passage intéressant à 47 minutes et 12 secondes donne une erreur si on lui demande 4 800 secondes, et c’est explicite plutôt que de retourner une image par défaut. La limite de 24 heures du contrôle est un confort d’interface, pas une promesse sur ce que le MOV contient réellement.

Le décodeur de la vidéo et l’encodeur WebP sont chargés à la demande, et tournent dans le même processus que l’onglet. Aucune requête ne porte le fichier MOV, et l’onglet réseau des outils de développement est vide pendant la conversion. C’est la forme de conversion qui convient pour une image sous embargo ou une scène de film à protéger, et c’est la même garantie que pour le reste de la chaîne audio et vidéo du navigateur.

La taille maximale acceptée par la version gratuite est 100 Mo par fichier, et c’est la même limite que pour toute la chaîne vidéo. Un MOV de plusieurs gigaoctets est rejeté à la frontière du drop, et c’est explicite : pour les longs enregistrements, découper avant la conversion, plutôt que de chercher à faire passer un fichier d’une heure par un service qui n’a pas la place de le recevoir.

Un MOV dont l’index est cassé, dont l’atome mdat est mal fermé, ou qui porte un codec vidéo que la machine ne reconnaît pas, échoue avec un message lisible. La conversion ne devine pas, ne tente pas de prendre la première image disponible, et ne produit pas une image par défaut : ce serait pire qu’une erreur franche, parce qu’une image qui ne correspond à rien est silencieusement fausse.

Pour un MOV produit par un téléphone ou une caméra, ces cas sont rares, parce que le matériel respecte la spec. Pour un MOV retravaillé dans un éditeur qui a mal refermé son conteneur, l’erreur est un indice à donner à l’auteur du fichier, qui saura ré-exporter depuis sa timeline plutôt que depuis son dossier de rendu. Le MOV qui ne se lit pas est un problème en amont, et le signaler est plus utile que de le masquer.