Pivoter une vidéo de 90° ou 180° : l'indicateur ou les pixels

Deux opérations qui se ressemblent et n'ont rien à voir

Un fichier vidéo peut être pivoté de deux manières. La première écrit une petite instruction dans le conteneur — une matrice d'affichage, dans la famille MP4 et QuickTime — qui dit « affiche ceci tourné de 90 degrés ». Les pixels ne bougent pas, l'opération prend le temps de réécrire quelques dizaines d'octets, et elle est parfaitement réversible. La seconde décode chaque image, déplace les pixels et les recompresse. Cela prend des minutes plutôt que des millisecondes, coûte une génération de compression avec perte, et ne se défait pas.

Le problème de l'indicateur, c'est qu'il n'est qu'un conseil. Un lecteur doit lire le conteneur, y trouver la matrice et l'appliquer, et tous ne le font pas. Les lecteurs web l'honorent de façon inégale, certains logiciels de montage importent les images brutes en ignorant l'instruction, des box et des téléviseurs anciens ne l'ont jamais apprise, et quelques outils l'appliquent une seconde fois par-dessus un lecteur qui l'avait déjà fait — c'est ainsi qu'un clip finit à l'envers. L'indicateur est instantané, sans perte, et parfois désobéi ; le réencodage est lent, avec perte, et toujours obéi. Il n'existe pas de troisième voie qui soit les deux.

Cet outil a choisi la seconde voie délibérément, et il le dit dans une ligne sous ses commandes : la rotation est écrite dans l'image elle-même, pas dans un indicateur que certains lecteurs ignorent et que d'autres appliquent deux fois, et c'est pour cela qu'il y a réencodage. C'est une description honnête du code. Le tableau ci-dessous expose le marché en entier, pour que tu décides si tu le veux avant d'y passer des minutes.

Ton clip de téléphone couché n'a peut-être pas besoin d'être pivoté

C'est la raison la plus fréquente d'arriver sur un outil de rotation, et c'est généralement le mauvais remède. Un téléphone enregistre avec son capteur dans une orientation fixe et écrit un indicateur de rotation décrivant comment tu le tenais. Le fichier est donc correct : les pixels sont en paysage, l'indicateur dit « quart de tour », et toute application qui lit l'indicateur affiche la vidéo à l'endroit. Quand une application l'affiche couchée, c'est cette application qui est en tort, pas le fichier.

L'outil ne montre pas l'indicateur existant, et c'est sa fonction manquante la plus utile. Il lit les dimensions du clip depuis un élément vidéo caché dans la page, et les navigateurs rapportent déjà ces dimensions après application de la rotation — un clip portrait apparaît donc comme portrait, correctement, sans rien qui dise si c'est parce que les pixels sont en portrait ou parce qu'un indicateur l'a demandé. Depuis l'outil, tu ne peux pas distinguer les deux. Fais la vérification dehors : ouvre le clip dans deux lecteurs différents. Si l'un l'affiche à l'endroit et l'autre couché, il y a un indicateur, le fichier va bien, et le réencoder ne te coûtera que de la qualité. Si tous les lecteurs l'affichent couché, les pixels sont réellement couchés et c'est le bon outil.

Une garantie si tu y vas quand même. Cette version de ffmpeg applique l'indicateur de rotation existant avant ton filtre, donc la rotation demandée se compose avec l'indicateur au lieu de le combattre : la sortie correspond à l'aperçu, et elle ne porte plus d'indicateur ensuite. Tu n'obtiendras pas un clip tourné deux fois. Tu auras simplement payé un réencodage dont tu n'avais peut-être pas besoin.

Les cases miroir, l'aperçu en direct et le fichier

L'outil montre un aperçu en direct : ton clip qui joue, tourné en CSS, pour que tu voies le cadrage avant de valider. L'idée est bonne, et pendant un temps elle était juste pour toutes les combinaisons sauf quatre. L'aperçu appliquait sa transformation comme rotation puis échelle, et le CSS compose ces opérations de droite à gauche — le miroir passait donc en premier et la rotation en second. La chaîne de filtres fait l'inverse : transpose d'abord, les miroirs ajoutés ensuite. Rotation et miroir ne commutent pas, ces deux ordres ne donnent donc pas la même image, et un quart de tour avec exactement une case miroir produisait un fichier à un demi-tour de l'aperçu. L'aperçu écrit désormais échelle puis rotation, ce qui se compose en rotation-puis-miroir et rejoint la chaîne. Le fichier a toujours été le bon ; c'est l'image qu'on en donnait qui mentait.

Passer les deux ordres dans le même encodeur tranche la question. Sur le même clip de test, transpose=1,hflip et hflip,transpose=1 ont produit deux images différentes — nombre d'octets différent, sommes de contrôle différentes — alors que lancer deux fois la même commande a donné une sortie identique octet pour octet : la différence est donc réelle et non du bruit d'encodage. Coche les deux miroirs ensemble et le désaccord disparaît : transpose=1,hflip,vflip et hflip,vflip,transpose=1 ont donné la même image, parce qu'une paire de miroirs est un demi-tour et qu'un demi-tour commute avec tout.

En pratique, les seize combinaisons de boutons s'accordent désormais avec l'aperçu, et le contournement en deux passes que cet article recommandait — tourner d'abord, télécharger, puis relancer le téléchargement avec le seul miroir — n'a plus lieu d'être. Si tu trouves une combinaison où le fichier ne correspond pas à ce que tu as vu, ça vaut la peine de le signaler : ce serait un défaut nouveau, pas celui-ci.

Ce qu'il advient du son, et pourquoi le fichier grossit

Le son n'est jamais recopié tel quel. Garde-le et il est réencodé en AAC à 192 kbit/s, ou en Opus au même débit si la source est en WebM ; retire-le et les arguments audio deviennent -an, ce qui supprime la piste au lieu de la rendre muette. Réencoder un son déjà compressé avec perte, c'est une deuxième génération, et même si 192 kbit/s est assez généreux pour que la plupart des gens n'entendent rien, ce n'est pas rien. Si le son compte et que l'image n'a pas besoin d'être parfaite, envisage d'extraire l'audio d'abord et de le remettre ensuite.

L'image est encodée en libx264 au préréglage ultrafast et CRF 23. Ultrafast est le plus rapide des onze préréglages de vitesse et le moins efficace : il saute l'essentiel de l'analyse qui permet de dépenser moins de bits à qualité égale, ce qui est le bon compromis pour un seul fil du navigateur et le mauvais pour la taille du fichier. Sur le clip de test, un fichier 1080x1920 de 6 secondes pesant 493 466 octets est revenu à 513 371 octets après une rotation de 90 degrés. Rien n'a été ajouté à la vidéo ; il a simplement fallu plus de bits pour stocker moins bien les mêmes images. Attends-toi au même profil sur tes propres clips : pivoter n'est pas une étape de compression, et le traiter comme telle te décevra.

Questions fréquentes

Un quart de tour à gauche est-il pire qu'un quart de tour à droite ?

Non. Ce sont la même opération avec un paramètre différent : transpose=1 dans le sens horaire, transpose=2 dans l'autre. Les deux déplacent chaque pixel exactement une fois, coûtent le même temps et déclenchent le même unique réencodage. Le bouton 180 degrés n'est pas pire non plus, bien qu'il soit réalisé avec deux miroirs plutôt que deux rotations — lancer hflip,vflip et transpose=1,transpose=1 sur la même image a donné une sortie identique octet pour octet : le raccourci est donc exact autant que rapide.

Pourquoi mon fichier pivoté est-il plus lourd que l'original ?

Parce qu'il a été réencodé, et que les réglages de l'encodeur privilégient la vitesse sur la taille. L'outil utilise libx264 avec le préréglage ultrafast, qui fait très peu de l'analyse dont un préréglage plus lent se sert pour faire tenir la même image dans moins de bits, avec une cible de qualité constante à CRF 23. Si l'original a été compressé par un encodeur patient — la puce d'un téléphone, ou un logiciel de montage qui exporte toute la nuit — alors une seconde passe pressée à qualité comparable a réellement besoin de plus de place. Une hausse de 4 % a été mesurée sur le clip de test ; une source bien compressée peut grossir davantage. Rien n'a échoué ; tu vois le coût d'un réencodage, qui est le prix de la compatibilité universelle.

Ma vidéo est à l'endroit sur mon téléphone et couchée sur mon ordinateur. Que faire ?

C'est la signature d'un indicateur de rotation honoré par un programme et ignoré par un autre : le fichier n'est donc pas cassé. Si le seul programme qui se trompe est un programme que tu utilises rarement, laisse le fichier tranquille. S'il doit être correct partout — parce que tu le mets en ligne, l'envoies à quelqu'un ou l'importes dans un logiciel de montage qui ignore les indicateurs — alors réencode-le ici, en acceptant une génération de perte en échange d'un fichier qui n'a plus rien à mal interpréter. Ne réencode pas un fichier déjà correct là où ça compte pour toi.

L'outil peut-il pivoter un clip deux fois par accident ?

Pas pour la rotation elle-même. La version de ffmpeg derrière l'outil applique tout indicateur de rotation existant avant ton filtre et n'en écrit aucun dans la sortie : un quart de tour demandé sur un clip porteur d'indicateur donne un quart de tour au total, pas deux. L'aperçu s'accorde lui aussi avec le fichier : il composait sa transformation CSS dans l'ordre inverse de la chaîne de filtres, ce qui plaçait un quart de tour combiné à exactement un miroir à un demi-tour de ce que tu avais validé, et cela a été corrigé du côté de l'aperçu, pas du côté de la sortie.

Puis-je pivoter ici sans réencoder ?

Non. L'outil n'a qu'un chemin et il passe par l'encodeur ; il n'y a ni mode « indicateur seul » ni option de copie de flux. C'est un choix délibéré plutôt qu'un oubli — une rotation par indicateur seul est l'opération la plus susceptible de produire un fichier qui semble réparé sur la machine où tu l'as réparé et faux sur celle à qui tu l'envoies, ce qui est un mauvais résultat pour un outil dont les utilisateurs ne peuvent en général pas vérifier. Si tu veux précisément la voie des métadonnées, il te faut un outil en ligne de commande ou un éditeur de conteneur. Si tu veux un fichier correct partout sans y penser, c'est celui-ci.