Faire passer une vidéo sous une limite d'envoi sans tâtonner

La taille, c'est le débit multiplié par la durée, ou presque

Un fichier vidéo est un flux de bits restitué à un certain rythme. Multiplie ce rythme par la durée de lecture et tu obtiens le fichier, à la comptabilité propre du conteneur près, qui pour un MP4 normal représente une fraction de pour cent. Voilà pourquoi la taille n'est pas vraiment une propriété que l'on règle. C'est un résultat. Les deux choses réellement sous ton contrôle sont le nombre de bits qui défilent chaque seconde et le nombre de secondes, et tout ce que fait un compresseur est une manière d'appuyer sur la première.

La conversion mérite d'être retenue, parce qu'elle est toute la méthode. Un mégaoctet vaut huit millions de bits, donc un mégaoctet vaut 8 000 kilobits. Multiplie la limite en mégaoctets par 8 000, divise par le nombre de secondes, et le résultat est le débit total en kilobits par seconde qui tient. Une limite de 25 Mo sur un plan de 60 secondes autorise 3 333 kbit/s. La même limite sur un plan de 10 minutes autorise 333 kbit/s. Même limite, vingt fois moins de place, et toute la différence tient à la durée.

Un piège dans ce calcul est le mégaoctet lui-même. Certains systèmes entendent par là 1 000 000 d'octets, d'autres 1 048 576, soit un écart de 4,9 %, et un service dit rarement lequel il applique. Calculer avec la valeur décimale — 8 000 kilobits par mégaoctet — est le bon sens dans lequel se tromper : si le service visait en réalité le plus gros mégaoctet, ton fichier passe simplement sous la limite avec de la marge.

Le CRF demande une qualité, pas une taille

Le curseur de qualité de cet outil règle un facteur de qualité constante. L'échelle va de 0 à 51 dans l'encodeur ; le curseur en expose 18 à 34, c'est-à-dire la portion qu'utilise toute personne raisonnable, et il démarre à 28. Un nombre plus bas signifie meilleure qualité et davantage de bits. Le guide de FFmpeg qualifie 17 ou 18 de visuellement sans perte ou presque, et décrit 17 à 28 comme la plage subjectivement raisonnable. La propriété décisive est le sens du nombre : c'est une consigne sur la quantité de dégradation tolérée dans chaque image, pas sur le nombre de bits à produire.

C'est pourquoi le même CRF donne des tailles très différentes selon les plans. Deux minutes d'entretien statique en CRF 23 tiendront peut-être en quelques mégaoctets ; deux minutes de pluie sur l'eau, de confettis ou de marche caméra à l'épaule dans un marché au même CRF peuvent en peser dix fois plus, parce que tenir la même qualité visuelle à travers tout ce mouvement coûte réellement davantage de bits. L'encodeur fait ce que tu as demandé. Tu as demandé une apparence, pas un poids. La documentation de FFmpeg le dit explicitement : dans ce mode, on ne peut pas lui imposer une taille de fichier ni un plafond de débit.

Il existe une régularité sur laquelle s'appuyer, et c'est la raison pour laquelle deux essais convergent si vite. L'échelle CRF est exponentielle : l'augmenter de six points divise à peu près le débit par deux, la baisser de six le double à peu près. Cette seule règle transforme un curseur aveugle en instrument de visée. Sur la plage exposée par cet outil, de 18 à 34, cela représente un facteur d'environ 6,3 entre le plus gros et le plus petit fichier qu'un même plan peut produire.

Remonter depuis la limite, avec un exemple réel

Prends un plan de trois minutes que tu veux envoyer par courriel. Gmail annonce une limite de pièce jointe de 25 Mo sur les comptes personnels, donc : 25 × 8 000 = 200 000 kilobits, divisés par 180 secondes, soit 1 111 kbit/s au total. Retire les 128 kbit/s que cet outil consacre à l'audio et il reste 983 kbit/s pour l'image. La recommandation publiée par YouTube pour du 1080p à cadence standard est de 8 000 kbit/s. On te demande de le faire avec un huitième. Le plan s'encodera, et il aura l'air d'avoir été filmé à travers une vitre sous la pluie.

Change donc la question. En 720p, la recommandation de YouTube est de 5 000 kbit/s et tu en as 983 — encore un cinquième. En 480p elle est de 2 500 et tu en as 983, soit 39 % : agressif, visiblement plus mou, mais regardable pour un plan de parole ou une capture d'écran. Cette comparaison est la vraie décision, et il a fallu une division pour y arriver. Si le plan doit rester en 1080p, le seul levier restant est la durée : coupe-le à 45 secondes et les mêmes 25 Mo te donnent 4 444 kbit/s au total et 4 316 pour l'image — proche de la recommandation 720p et un peu plus de la moitié de celle du 1080p, seuil à partir duquel monter le CRF cesse d'être une brutalité.

Quand le calcul dit non

Fais la division sur un enregistrement de trente minutes face à une limite de 25 Mo et tu obtiens 111 kbit/s au total — moins que ce dont l'audio a besoin à lui seul. Le budget image est négatif. Aucun réglage de compression ne résout cela, et aucune patience n'y changera rien, parce que la demande est arithmétiquement impossible avant même que l'encodeur entre en jeu. C'est le résultat le plus utile que produise la méthode, et il vaut mieux y arriver avant de passer vingt minutes à encoder.

Les réponses honnêtes à ce stade portent toutes sur la durée ou sur le destinataire. Coupe l'enregistrement à la partie qui compte — l'outil de découpe le fera en quelques secondes sans rien ré-encoder, au prix d'atterrir sur une image-clé plutôt qu'exactement là où tu l'avais demandé. Découpe-le en morceaux. Ou change de canal : les pages d'aide de WhatsApp annoncent une limite vidéo par défaut de 100 Mo et 720p sur une connexion rapide, 64 Mo et 480p sur une connexion lente, tandis que les documents envoyés par la même application montent à 2 Go — envoyer une vidéo en tant que document contourne donc à la fois la limite de taille et la recompression de l'application.

L'option qui déplace l'index au début

Chaque MP4 produit par cet outil est écrit avec +faststart, et cela mérite un paragraphe, car c'est la différence entre un fichier qui se lit et un fichier qui semble cassé. Un MP4 range ses données média dans une boîte et son index — la table indiquant où se trouve chaque image, appelée atome moov — dans une autre. Par défaut, l'encodeur écrit l'index en dernier, parce qu'il ne peut pas connaître la disposition finale avant la dernière image. Un lecteur qui lit un tel fichier depuis un serveur web doit atteindre la fin du téléchargement avant de pouvoir démarrer.

L'option faststart fait effectuer à l'encodeur une seconde passe sur le fichier terminé pour déplacer cet index au début. La documentation de FFmpeg la décrit exactement ainsi, et précise qu'elle n'est pas active par défaut parce que cette passe supplémentaire prend du temps. YouTube demande la même chose dans ses recommandations d'envoi : l'atome moov en tête de fichier, qu'il appelle Fast Start. L'effet pratique est que ta vidéo commence à se lire pendant qu'elle arrive encore, au lieu d'afficher un rectangle noir jusqu'au dernier octet — ce que feront un aperçu d'envoi, un client de messagerie ou une page web avec un fichier qui en est dépourvu.

Ce que l'outil exécute réellement, et où

Il n'y a aucun mystère dans la chaîne, la voici donc en entier. Le compresseur encode l'image avec libx264 au préréglage veryfast et le CRF que tu as choisi, encode le son en AAC à 128 kbit/s, et écrit le résultat en MP4 avec l'option faststart. C'est toute la commande. Le préréglage est un cadran vitesse-contre-efficacité et non un cadran de qualité : un préréglage plus lent produirait un fichier légèrement plus petit au même CRF, et veryfast est le compromis qui évite qu'un encodage dans le navigateur ne prenne l'après-midi.

Cet encodeur est FFmpeg compilé en WebAssembly, et il tourne dans la page, sur ta machine. Le moteur pèse environ 32 Mo et il est servi depuis l'adresse de ce site plutôt que depuis un réseau tiers : la seule chose qui circule est le moteur qui vient à toi — la vidéo ne va nulle part. La compilation est monothread, ce qui explique qu'elle soit plus lente qu'un encodeur de bureau qui répartit le travail sur tous tes cœurs, et qu'un long plan représente vraiment une longue attente. Garde l'onglet au premier plan pendant le travail : la tâche vit dans la page et aucun serveur ne te garde ta place.

Questions fréquentes

Pourquoi ne puis-je pas simplement saisir la taille voulue ?

Parce qu'atteindre une taille exacte suppose que l'encodeur voie tout le plan avant de décider comment dépenser ses bits, donc qu'il l'encode deux fois. C'est ce que fait le mode deux passes : la première mesure où sont les moments difficiles, la seconde répartit le budget en conséquence. C'est la bonne réponse quand la taille est une contrainte dure, et cela coûte à peu près le double de temps. Cet outil fait une seule passe à qualité constante, ce qui est le bon arbitrage pour un encodeur dans le navigateur, où la seconde passe doublerait une attente déjà longue. L'arithmétique de cet article sert à faire atterrir le CRF en une passe là où les deux passes atterriraient.

Mon fichier compressé est plus gros que l'original. Comment ?

Parce que le CRF demandé était plus généreux que la qualité que le fichier possédait déjà. La compression n'est pas un cliquet : l'encodeur ignore et se moque du poids d'entrée, il produit simplement ce que coûte un niveau de qualité donné. Un plan déjà fortement compressé, un fichier téléchargé depuis une messagerie ou une capture d'écran au contenu majoritairement fixe peut réclamer plus de bits en CRF 23 qu'il n'en occupe actuellement. Monte le CRF. L'autre cause fréquente est une piste audio initialement inférieure à 128 kbit/s, puisque cet outil la ré-encode toujours à ce débit.

Faut-il baisser la résolution ou monter le CRF ?

Compare ton budget à ce que réclame la résolution et laisse l'écart trancher. Si le budget est à un facteur deux de la recommandation, monte le CRF : l'image s'adoucira mais gardera des contours nets. S'il en représente un cinquième ou moins, baisse plutôt la résolution : un encodeur affamé à ce point produit du blocage et des bavures bien plus laids que la même matière rendue honnêtement à une taille moindre. En règle générale, une image qui manque de pixels paraît petite, une image qui manque de bits paraît cassée, et le spectateur pardonne bien plus volontiers la première.

Le réglage audio a-t-il la moindre importance ?

Il compte exactement quand le plan est long et la limite petite. À 128 kbit/s le son coûte environ 0,96 Mo par minute : un plan de deux minutes consacre moins de 2 Mo à l'audio et personne n'y prête attention, tandis qu'un enregistrement de vingt minutes y consacre plus de 19 Mo — d'où l'impossibilité de la ligne trente minutes du tableau à 25 Mo. Cet outil n'expose pas de réglage audio ; quand le son est le problème, la réponse est de raccourcir l'enregistrement, ou d'admettre qu'une longue prise de parole appelle un tout autre format et d'en extraire la piste audio seule.

L'envoi a échoué alors que mon fichier est sous la limite annoncée.

Trois causes reviennent régulièrement. La limite annoncée peut porter sur le message entier plutôt que sur chaque pièce jointe : tes autres fichiers comptent alors aussi. Le service peut mesurer l'envoi encodé plutôt que le fichier sur disque, ce qui ajoute environ un tiers pour une pièce jointe de courriel. Et les chiffres publiés vieillissent : la page d'aide de Discord sur les pièces jointes, consultée le 13 août 2026, indique que la limite gratuite est désormais de 20 Mo, relevée depuis 10 Mo en août 2026, avec 50 Mo pour Nitro Basic et jusqu'à 500 Mo pour Nitro — alors qu'un paragraphe plus ancien de la même page dit encore 10 Mo. Quand une page se contredit, vise sous le plus petit chiffre.