1 line
25 KiB
JSON
1 line
25 KiB
JSON
[{"uuid":"df21d7f5-1fe2-49a6-aced-91461bbf525f","slug":"forcer-la-reinitialisation-d-un-mot-de-passe-nextcloud","title":"Forcer la réinitialisation d'un mot de passe utilisateur NextCloud","category":"Informatique","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2023-02-09 16:12:18","created_at":"2023-02-09 16:12:18","updated_at":"2023-02-09 16:12:18","tags":[],"plain":"Pour réinitialiser le mot d'un utilisateur, il est possible de le faire en ligne de commande. Par exemple, pour réinitialiser le mot de passe du compte admin :"},{"uuid":"a39e992f-3f28-44ca-9f04-5f1d5f8cd5d9","slug":"enregistrer-votre-nom-d-utilisateur-et-votre-mot-de-passe-dans-git","title":"[N] Enregistrer votre nom d utilisateur et votre mot de passe dans git","category":"Journal geek","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2023-01-07 19:29:00","created_at":"2023-01-07 19:29:00","updated_at":"2023-01-07 19:29:00","tags":[],"plain":"Pour enregistrer votre nom d'utilisateur et votre mot de passe dans Git, vous pouvez utiliser la commande et définir les propriétés et . Par exemple : Il faut toutefois noter que l'enregistrement de votre mot de passe dans Git peut être risqué du point de vue de la sécurité, car toute personne ayant accès à votre référentiel pourrait le voir. Il est généralement préférable d'utiliser une clé ssh pour l'authentification ou un utilitaire de gestion des informations d'identification pour stocker vos informations d'identification de manière sécurisée. Pour utiliser un utilitaire de gestion des informations d'identification, vous pouvez exécuter la commande suivante : Remplacez par le nom de l'utilitaire de gestion des informations d'identification que vous souhaitez utiliser. Certains utilisateurs populaires incluent , et . Sur Linux, vous pouvez utiliser l'utilitaire de gestion des informations d'identification ou pour stocker vos informations d'identification de manière sécurisée. stocke vos informations d'identification en mémoire pendant un certain temps (par défaut, 15 minutes). Vous pouvez ajuster la durée avec l'option de configuration . Par exemple, pour stocker vos informations d'identification pendant une heure, vous pouvez utiliser la commande suivante : stocke vos informations d'identification de manière permanente sur votre disque dur, dans un fichier caché dans votre répertoire utilisateur. Pour utiliser , exécutez la commande suivante : Notez que les utilisateurs de Linux peuvent également utiliser d'autres utilisateurs de gestion des informations d'identification, tels que ou , en fonction de leur environnement de bureau. Pour utiliser comme utilitaire de gestion des informations d'identification dans Git, vous devez d'abord vous assurer que est installé sur votre système. Si ce n'est pas le cas, vous pouvez l'installer en utilisant votre gestionnaire de paquets préféré (par exemple, sous Ubuntu, sous Fedora). Il se peut que vous ayez besoin d'installer une bibliothèque supplémentaire pour utiliser . Si ce fichier n'est pas disponible sur votre système, vous pouvez essayer d'installer le paquet . ??????????????? A compléter ici Voici comment installer gnome-keyring-devel avec : Une fois installé, vous pouvez utiliser la commande suivante pour configurer Git pour l'utiliser : Cela configure Git pour utiliser comme utilitaire de gestion des informations d'identification. Lorsque vous effectuez une action nécessitant des informations d'identification, Git vous demandera d'entrer votre nom d'utilisateur et votre mot de passe. Si vous cochez la case \"Se souvenir de cet ordinateur\", vos informations d'identification seront stockées de manière sécurisée dans le Keyring de GNOME et utilisées automatiquement lors de futures actions. Notez que n'est disponible que sur les systèmes utilisant GNOME comme environnement de bureau. Si vous utilisez un autre environnement de bureau, vous devrez utiliser un autre utilitaire de gestion des informations d'identification compatible avec votre environnement. est un utilitaire de gestion des informations d'identification disponible sur macOS. Il permet de stocker vos informations d'identification de manière sécurisée dans le gestionnaire de mots de passe de macOS, le Keychain. Pour utiliser comme utilitaire de gestion des informations d'identification dans Git, vous pouvez exécuter la commande suivante : Cela configure Git pour utiliser comme utilitaire de gestion des informations d'identification. Lorsque vous effectuez une action nécessitant des informations d'identification, Git vous demandera d'entrer votre nom d'utilisateur et votre mot de passe. Si vous cochez la case \"Se souvenir de cet ordinateur\", vos informations d'identification seront stockées de manière sécurisée dans le Keychain et utilisées automatiquement lors de futures actions. Où est le nom du dépôt distant vers lequel vous souhaitez envoyer les commits et est la branche sur laquelle vous souhaitez envoyer les commits. ou"},{"uuid":"093711bf-4e60-4ea8-ba73-928d2d67776c","slug":"certificats-let-s-encrypt-a-6-jours-faut-il-sauter-le-pas","title":"Certificats Let's Encrypt à 6 jours : faut-il sauter le pas ?","category":"actualité","author":"cedric@abonnel.fr","cover":"cover.svg","published":true,"published_at":"2026-05-07 22:46","created_at":"2026-05-12 08:47:27","updated_at":"2026-05-12 08:59:58","tags":[],"plain":"Guide DevOps / WebOps pour comprendre les certificats à durée de vie courte () et décider si vous devez migrer.\r\n--\r\n\r\nTL;DR\r\n\r\nLet's Encrypt propose désormais au grand public des certificats valides 6 jours (profil ), en plus du classique 90 jours. Pour les certificats sur adresse IP, c'est même obligatoire. La question n'est pas \"est-ce que c'est bien ?\" — techniquement oui — mais \"est-ce que mon infra est prête ?\". Si votre renouvellement automatique fonctionne sans accroc depuis 6 mois, foncez. Sinon, fiabilisez d'abord, migrez ensuite.\r\n--\r\n\r\n1. De quoi on parle\r\n\r\nDepuis janvier 2026, Let's Encrypt émet en disponibilité générale deux nouveautés couplées : les certificats pour adresses IP, et les certificats à durée de vie de 6 jours via un nouveau profil ACME nommé . Certbot 4.0 a introduit le flag pour les sélectionner, et Certbot 5.3 a ajouté pour demander un cert sur IP.\r\n\r\nConcrètement, un certificat a une validité de 6 jours au lieu de 90. Tout le reste — chaîne de confiance, algorithmes, format — est identique. Pour le navigateur, c'est un certificat Let's Encrypt standard.\r\n\r\nLes profils disponibles\r\nProfil | Durée | Usage |\r\n---|---|---|\r\n(défaut) | 90 jours | Tout le monde, par défaut |\r\n| 6 jours | Adopters précoces, certs sur IP (obligatoire) |\r\n| 90 jours | Variante optimisée serveur web (sans clientAuth) |\r\n--\r\n\r\n2. Pourquoi Let's Encrypt pousse vers le court\r\n\r\nQuatre raisons techniques, par ordre d'importance.\r\n\r\n2.1 La révocation TLS est cassée — autant l'éviter\r\n\r\nC'est le vrai sujet. Le mécanisme de révocation des certificats (CRL, OCSP) n'a jamais fonctionné correctement à grande échelle :\r\nOCSP soft-fail : si le serveur OCSP est injoignable, la plupart des navigateurs acceptent quand même le certificat. Un attaquant qui contrôle le réseau bloque l'OCSP et le cert révoqué passe.\r\nOCSP stapling mal configuré sur beaucoup de serveurs.\r\nCRLite, OneCRL : couvertures partielles, déploiement client incohérent.\r\nOCSP retiré : Let's Encrypt a arrêté OCSP en 2025, justement parce que ça ne servait quasiment à rien tout en posant des problèmes de vie privée.\r\n\r\nAvec un cert à 6 jours, la révocation devient cosmétique : on attend l'expiration. La fenêtre d'exploitation d'une clé compromise passe de plusieurs semaines (cert 90 jours, OCSP douteux) à quelques jours maximum.\r\n\r\n2.2 Réduire la fenêtre de compromission\r\n\r\nSi votre clé privée fuite (backup mal protégé, faille serveur, employé qui part avec une copie, vulnérabilité type Heartbleed), l'attaquant peut usurper votre site tant que le cert est valide. À 90 jours, c'est trois mois d'exposition dans le pire cas. À 6 jours, c'est une semaine.\r\n\r\nC'est encore plus critique pour les certs sur IP : une IP peut changer de propriétaire (cloud, VPS recyclé, réattribution FAI). Un cert long pour une IP qui ne vous appartient plus, c'est un risque que LE refuse de prendre — d'où l'obligation du profil court pour cet usage.\r\n\r\n2.3 Forcer une automatisation propre\r\n\r\nPersonne ne renouvelle un cert à la main tous les 6 jours. C'est mécaniquement infaisable. Le profil est donc un filtre qualité : si votre renouvellement n'est pas blindé, vous le saurez vite.\r\n\r\nL'effet de bord positif : ça élimine les pannes classiques type \"le cert a expiré parce que le cron était cassé depuis trois mois et personne ne s'en est rendu compte\". À 6 jours, un cron cassé devient visible immédiatement.\r\n\r\n2.4 Agilité cryptographique\r\n\r\nSi une vulnérabilité majeure impose de déprécier un algorithme en urgence (RSA, transition post-quantique, faille découverte sur SHA-256), un parc avec des certs à 6 jours bascule en une semaine. Un parc 90 jours met trois mois. C'est la raison qui motive aussi le CA/Browser Forum à pousser globalement vers des durées plus courtes (45 jours d'ici 2029 dans la baseline).\r\n--\r\n\r\n3. Pourquoi vous pourriez ne pas migrer\r\n\r\nSoyons honnêtes : pour la plupart des infras web classiques, le 90 jours suffit largement. Le 6 jours a des coûts réels.\r\n\r\n3.1 Pression sur le rate limiting\r\n\r\nLet's Encrypt limite à 300 nouveaux certificats par compte par 3 heures et 5 duplicatas de cert par semaine. Avec des certs 90 jours, vous renouvelez 4 fois par an. Avec des 6 jours, c'est 60 fois par an et par cert. Si vous avez 50 services derrière 50 certs distincts, vous explosez votre budget de requêtes ACME.\r\n\r\nMitigation : regrouper les domaines dans des certs SAN (un seul cert pour , , plutôt que trois certs).\r\n\r\n3.2 Dépendance critique au CA et au réseau\r\n\r\nÀ 90 jours, si Let's Encrypt est down 48h, vous ne le remarquez même pas. À 6 jours, une panne de 48h sur LE et votre fenêtre de renouvellement (typiquement à 1/3 de la durée restante, soit 2 jours), et votre cert expire. Vos services tombent.\r\n\r\nConséquences concrètes :\r\nIl faut un monitoring sérieux de l'expiration des certs (Prometheus blackbox exporter, , etc.).\r\nIl faut un fallback : second client ACME, second account, ou cert de secours d'une autre CA.\r\nIl faut absolument que la résolution DNS et le port 80/443 sortants depuis votre serveur soient fiables.\r\n\r\n3.3 Charge sur les systèmes de déploiement\r\n\r\nChaque renouvellement déclenche : appel ACME, validation HTTP-01 ou DNS-01, écriture des fichiers, rechargement du serveur web (Nginx, Apache, HAProxy, etc.). À 60 fois par an au lieu de 4, ça multiplie par 15 le nombre de reloads.\r\n\r\nSur un serveur web basique, un est gratuit. Sur des architectures plus complexes (load balancers stateful, terminations TLS distribuées, certs poussés vers un CDN, configs multi-nœuds avec Ansible/Salt), chaque renouvellement déclenche une cascade. À évaluer.\r\n\r\n3.4 Logs, audit, conformité\r\n\r\nCertains contextes réglementaires demandent une traçabilité des certificats (PCI-DSS, ISO 27001, HDS). Multiplier par 15 le volume d'événements de renouvellement à archiver et auditer, ça représente du stockage et du tooling à adapter.\r\n\r\n3.5 Le cas \"monitoring TLS externe\"\r\n\r\nSi vous avez des outils tiers (uptime monitors, scanners de conformité) qui vérifient l'expiration de vos certs, ils risquent de hurler en permanence : un cert qui montre toujours \"expire dans 6 jours\" déclenche les alertes \"cert expirant bientôt\" sur la plupart des outils mal configurés. Il faut soit ajuster les seuils, soit changer d'outil.\r\n--\r\n\r\n4. Décision : grille de lecture\r\nSituation | Recommandation |\r\n---|---|\r\nServeurs web classiques, renouvellement Certbot qui marche, < 20 certs | Restez en 90 jours. Le bénéfice marginal ne justifie pas le risque. |\r\nVous gérez des certs sur IP | Pas le choix : est obligatoire. |\r\nArchitecture critique avec rotation de clés agressive (banque, santé, infra publique) | Migrez. Le 6 jours est aligné avec vos exigences de sécurité. |\r\nInfra dev/staging interne | Excellent terrain de test. Migrez d'abord ici pour valider votre pipeline. |\r\nVous avez déjà eu une expiration cert non détectée en prod | Ne migrez pas tout de suite. Fiabilisez d'abord le monitoring et le renouvellement, puis migrez. Sinon vous transformez un incident annuel en incident hebdomadaire. |\r\nVous publiez via reverse proxy unique (un seul cert SAN pour plusieurs services) | Bon candidat. Un seul renouvellement à fiabiliser. |\r\nVous avez un parc hétérogène (Apache + Nginx + HAProxy + Traefik...) avec hooks custom | Auditez chaque hook avant de migrer. C'est là que ça casse. |\r\n--\r\n\r\n5. Comment migrer concrètement (Certbot)\r\n\r\n5.1 Pré-requis\r\n\r\nAvant tout :\r\n\r\n1. Certbot 4.0+ pour , 5.3+ pour , 5.4+ pour avec IP.\r\n2. Un renouvellement automatique opérationnel et vérifié (timer systemd ou cron actif, testé avec ).\r\n3. Un monitoring d'expiration des certs en place. Si vous n'en avez pas, installez-le avant de migrer.\r\n4. Un hook de reload du serveur web qui fonctionne ().\r\n\r\n5.2 Test sur le staging Let's Encrypt\r\n\r\n\r\n\r\nVérifier que le cert obtenu a bien une durée de 6 jours :\r\n\r\n\r\n\r\n5.3 Renouvellement plus fréquent\r\n\r\nPar défaut, Certbot renouvelle quand il reste 1/3 de la durée. Pour un cert 6 jours, ça veut dire renouveler à 2 jours restants. Ça laisse peu de marge en cas de panne. Vous pouvez forcer un renouvellement plus tôt :\r\n\r\n\r\n\r\nLe timer Certbot tourne deux fois par jour par défaut, ce qui est suffisant. Pas besoin de l'accélérer.\r\n\r\n5.4 Cas d'un certificat sur IP\r\n\r\n\r\n\r\nNote importante : Certbot ne sait pas encore installer automatiquement les certs IP dans Nginx ou Apache. Il faut éditer la config manuellement pour pointer vers et , et configurer un pour le reload.\r\n\r\n5.5 Plan de bascule recommandé\r\n\r\n1. Semaine 1-2 : un domaine non critique (un sous-domaine de test, un service interne) en . Surveillez les renouvellements.\r\n2. Semaine 3-4 : étendez à la moitié de votre dev/staging.\r\n3. Semaine 5-6 : migration progressive en prod, en commençant par les services les moins critiques.\r\n4. À tout moment : possibilité de retour arrière en supprimant du fichier de config Certbot dans .\r\n--\r\n\r\n6. Pièges à éviter\r\nNe migrez pas tout en même temps. Si votre hook de reload a un bug, vous le découvrez sur un seul service, pas sur 50.\r\nNe désactivez pas le monitoring d'expiration sous prétexte que c'est automatisé. L'automatisation peut casser silencieusement. Un check externe qui hurle à J-2 reste indispensable.\r\nAttention aux secrets stockés dans des configs autres que Certbot. Si vous avez des certs poussés manuellement vers un CDN, un load balancer cloud ou un firewall TLS-inspectant, le passage à 6 jours impose d'automatiser cette propagation aussi.\r\nPas de cert IP pour un service exposé publiquement à long terme. Si l'IP change, le cert devient inutilisable instantanément. Préférez le DNS quand c'est possible.\r\nVérifiez votre client ACME. Tous les clients ACME ne supportent pas encore les profils. acme.sh, Caddy, lego, Traefik : checkez la version. Certbot 4.0 minimum.\r\n--\r\n\r\n7. Verdict\r\n\r\nLe profil est techniquement supérieur au 90 jours sur le plan sécuritaire. Mais il déplace le coût : moins de risques liés aux clés compromises et à la révocation cassée, plus de risques liés à la chaîne de renouvellement.\r\n\r\nLa règle simple : si votre renouvellement automatique est fiable, migrez. Sinon, fiabilisez-le d'abord — la migration n'en sera que la conséquence naturelle.\r\n\r\nPour la majorité des infras web auto-hébergées (typiquement, un Proxmox + reverse proxy + une dizaine de services derrière), le 90 jours reste un excellent compromis. Le devient pertinent quand :\r\nVous avez besoin de certs sur IP (obligatoire).\r\nVous exploitez des services à forte exigence de sécurité (clés très sensibles).\r\nVous voulez tester votre résilience opérationnelle (le 6 jours est un excellent test de fiabilité de votre stack).\r\n\r\nLe reste du temps, gardez le 90 jours, dormez tranquille, et ressortez ce document quand le CA/Browser Forum imposera 45 jours par défaut (vers 2027-2028).\r\n--\r\n\r\nSources\r\nLet's Encrypt — Six-Day and IP Address Certificates Available in Certbot (mars 2026)\r\nLet's Encrypt — 6-day and IP address certs in general availability (janvier 2026)\r\nDocumentation Certbot — Hooks\r\nCA/Browser Forum Baseline Requirements"},{"uuid":"0eaa0f05-7f48-47b4-91d3-3ba4ac80fe50","slug":"clearview-ai-quand-l-intelligence-artificielle-depasse-les-limites-du-public","title":"Clearview AI : quand l’intelligence artificielle dépasse les limites du « public »","category":"actualité","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2025-11-05 07:15:36","created_at":"2025-11-05 07:15:36","updated_at":"2025-11-05 07:15:36","tags":[],"plain":"En 2019, une start-up américaine du nom de Clearview AI fait irruption dans le monde de la reconnaissance faciale. Son idée paraît révolutionnaire : créer une base de données géante pour identifier n’importe qui à partir d’une simple photo. Pour nourrir son intelligence artificielle, l’entreprise collecte des milliards d’images publiques issues de plateformes comme Facebook, LinkedIn, Twitter ou encore YouTube. Chaque cliché, chaque visage devient une donnée utile à l’algorithme — mais sans que les personnes concernées n’en soient informées, ni qu’elles aient donné leur consentement.\r\n\r\nRapidement, l’ampleur du projet suscite la controverse. Des journalistes révèlent les pratiques de Clearview, et les autorités de protection des données s’en emparent. En France, la CNIL sanctionne l’entreprise pour traitement illégal de données biométriques. Le régulateur britannique fait de même, imposant des amendes et interdisant l’usage de ces données en Europe. Ce scandale devient un symbole : il montre que même à l’ère numérique, la vie privée reste un droit fondamental, et que la technologie ne peut pas s’affranchir des règles éthiques et juridiques.\r\n\r\nL’affaire Clearview soulève un enjeu majeur : la frontière entre le contenu public et le contenu libre d’usage. Ce n’est pas parce qu’une image est visible en ligne qu’elle peut être exploitée pour entraîner une IA. Cette logique s’applique aussi à des plateformes comme LinkedIn : les informations qu’on y partage publiquement ne deviennent pas pour autant un matériau libre pour les algorithmes.\r\n\r\nAinsi, Clearview AI incarne à la fois la puissance et le danger de l’intelligence artificielle : un outil capable du meilleur, mais aussi du pire, lorsqu’il franchit la ligne fragile entre innovation et intrusion."},{"uuid":"4429f822-8710-4a2c-8c05-abe8b7e0f6fd","slug":"changer-de-resolution-d-une-video-avec-ffmpeg","title":"Changer de résolution d'une vidéo avec FFmpeg","category":"Informatique","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2023-03-08 18:08:49","created_at":"2023-03-08 18:08:49","updated_at":"2023-03-08 18:08:49","tags":[],"plain":"Dans ce tutoriel sur FFmpeg, nous allons apprendre à changer la résolution d'une vidéo en utilisant l'outil en ligne de commande de FFmpeg. Le changement de résolution est une opération courante en édition vidéo, en traitement et en compression. Il est souvent utilisé dans le contexte du streaming vidéo ABR, où une seule vidéo source est compressée en plusieurs combinaisons bitrate-resolution. Pour déterminer la résolution d'une vidéo d'entrée, nous allons utiliser l'outil , qui est inclus dans les compilations FFmpeg. Nous allons exécuter la commande suivante dans la ligne de commande pour récupérer la résolution de la vidéo d'entrée : ffprobe -v error -selectstreams v:0 -showentries stream=width,height -of csv=s=x:p=0 input.mp4 Cette commande utilise l'option pour sélectionner le flux vidéo de la vidéo d'entrée, pour afficher les informations sur la largeur et la hauteur du flux vidéo, et pour formater la sortie en une chaîne de caractères . L'outil affichera la résolution de la vidéo d'entrée sur la console. Mettre à l'échelle la résolution d'une vidéo\nPour mettre à l'échelle ou changer la résolution d'une vidéo à l'aide de FFmpeg, il est nécessaire d'utiliser le filtre d'échelle (scale filter) de FFmpeg. Pour utiliser ce filtre, voici la commande à utiliser: ffmpeg -i input.mp4 -vf scale=$w:$h <encoding-parameters> output.mp4 où et correspondent à la largeur et la hauteur souhaitées pour la vidéo de destination. Par exemple, peut être utilisé pour redimensionner la vidéo à une résolution de 480p. Après que FFmpeg ait changé la résolution de la vidéo, il va la réencoder avec cette nouvelle résolution. Dans la ligne de commande ci-dessus, des paramètres d'encodage peuvent être ajoutés pour encoder la vidéo mise à l'échelle avec ces paramètres. Par exemple, il est possible de demander à FFmpeg de l'encoder en utilisant pour obtenir un encodage H.264/AVC de qualité élevée, ou en utilisant d'autres paramètres selon le besoin. Changer la résolution d'une vidéo en conservant l'aspect ratio\nL'aspect ratio d'une image est très bien défini sur Wikipédia comme suit : l'aspect ratio d'une image est le rapport entre sa largeur et sa hauteur. Il est couramment exprimé sous forme de deux nombres séparés par un deux-points, comme dans 16:9. Pour un aspect ratio x:y, l'image est large de x unités et haute de y unités. Il est très courant de rencontrer ce problème lors du travail avec des vidéos : Comment changer la résolution d'une vidéo (ou la mettre à l'échelle) tout en gardant l'aspect ratio d'origine de la vidéo ? Dans FFmpeg, si vous souhaitez mettre à l'échelle une vidéo tout en conservant son aspect ratio, il est nécessaire de définir l'une des deux paramètres, la hauteur ou la largeur, et de définir l'autre paramètre à . Si vous définissez la hauteur, vous devez définir la largeur à et vice versa. Pour démontrer cela, supposons que les commandes suivantes prennent une vidéo HD (1920x1080) en entrée. Et, supposons que nous souhaitons changer sa résolution. Cela peut être fait de deux manières comme discuté précédemment, alors essayons les deux façons.\n- Spécifiez la largeur pour conserver l'aspect ratio ffmpeg -i input.mp4 -vf scale=320:-1 output.mp4 La vidéo résultante aura une résolution de 320x180. C'est parce que 1920/320 = 6. Ainsi, la hauteur est mise à l'échelle à 1080/6 = 180 pixels.\n- Spécifiez la hauteur pour conserver l'aspect ratio ffmpeg -i input.mp4 -vf scale=-1:720 output.mp4 La vidéo résultante aura une résolution de 1280x720. C'est parce que 1080/720 = 1,5. Ainsi, la largeur est mise à l'échelle à 1920/1,5 = 1280 pixels.\n- Pour plus d'informations sur l'utilisation de FFimpeg pour créer des vidéos à partir d'images ou pour d'autres tâches liées à la vidéo, veuillez vous référer à la documentation officielle de FFmpeg disponible sur leur site web. Protection contre l'upscalling\nChaque action de mise à l'échelle, à la hausse ou à la baisse, ne produira généralement pas le même niveau de qualité vidéo que la vidéo d'origine. Il est susceptible d'y avoir quelques pertes de compression lors du processus de mise à l'échelle. Si la résolution d'entrée est trop faible, FFmpeg offre une astuce pour éviter la mise à l'échelle. ffmpeg -i input.mp4 -vf \"scale='min(320,iw)':'min(240,ih)'\" output.mp4 Dans la ligne de commande ci-dessus, la largeur/hauteur minimale pour effectuer la mise à l'échelle est fixée respectivement à 320 et 240 pixels. Il s'agit d'une manière très simple de se protéger contre une mise à l'échelle de mauvaise qualité. Cela ne garantit pas une qualité de sortie exceptionnelle, mais cela permet de s'assurer que la qualité ne sera pas dégradée par l'ajout de pixels qui n'existent pas dans l'entrée originale. Pour plus d'informations sur l'utilisation de FFmpeg pour la mise à l'échelle de vidéos, veuillez vous référer à la documentation officielle de FFmpeg. Il est possible d'utiliser la commande suivante pour mettre à l'échelle la vidéo tout en conservant l'aspect ratio et en utilisant la largeur minimale de 320 pixels : ffmpeg -i input.mp4 -vf \"scale='min(320,iw)':'-1'\" output.mp4 Dans cette commande, la hauteur est définie à -1 pour que FFmpeg calcule automatiquement la hauteur en fonction de l'aspect ratio d'origine de la vidéo, tandis que la largeur est définie à la valeur minimale de 320 pixels."}] |