Pour une raison que je ne m'explique pas, parfois quand j'upload des vidéos sur mon WordPress, celles-ci ne fonctionnent pas correctement une fois l'article publié. Je pense que c'est parce qu'elles sont mal encodées et que par conséquent le navigateur ne sait pas les lire. Pour remédier à ça, je faisais donc un petit coup de FFmpeg , mais ouvrir le terminal et recoller les mêmes paramètres à chaque fois, c'était un peu lourdingue.

Alors j'ai repris un peu l'idée Magicbrake , mais en version automatique gérée directement dans le Finder de macOS. Un clic droit sur une ou plusieurs vidéos, et hop, le MP4 apparaît à côté de l'original sous le nom compressed_nom-original.mp4 et la source est préservée.

Étape 1 - Récupérer le kit

Je vous ai tout mis dans cette archive ZIP qui réunit le script, l'installateur, le désinstallateur et le mode d'emploi. Tout est sous licence MIT , donc modifiable et redistribuable.

Le seul prérequis est FFmpeg. Installez-le d'abord via Homebrew si nécessaire, puis lancez ceci dans le Terminal :

brew install ffmpeg

Étape 2 - Installer l'Action rapide

Décompressez l'archive. Dans le Terminal, tapez cd avec une espace, glissez le dossier compresser-video-macos dans la fenêtre et validez avec Entrée. Lancez ensuite :

chmod +x *.sh
./install.sh

L'installateur copie le convertisseur dans votre bibliothèque utilisateur et crée une Action rapide Automator dans le Finder. Du coup, aucune app de conversion à garder ouverte ni réglage à refaire.

L'Action rapide installée dans Automator, avec son unique script shell

Le hic, c'est que l'Action peut ne pas apparaître tout de suite. Relancez le Finder, ouvrez Actions rapides et cliquez sur Personnaliser… tout en bas. Activez ensuite Compresser la vidéo dans les extensions du Finder . Elle reste aussi disponible dans Services. Et si votre clic droit est désactivé, faites un Ctrl + clic sur le fichier.

Étape 3 - Compresser depuis le Finder

Sélectionnez une vidéo, ou carrément plusieurs, puis faites clic droit > Actions rapides > Compresser la vidéo. La conversion tourne en arrière-plan et, pour les vidéos un peu longues, un pourcentage d'avancement s'affiche dans la barre des menus en haut de l'écran. Une notification vous prévient quand le nouveau MP4 est prêt, dans le même dossier que sa source.

Le script ajoute compressed_ devant le nom, remplace l'extension par .mp4 et ne touche pas à l'original. Si ce nom existe déjà, il ajoute -2, puis -3. Pas d'écrasement !

Si l'Action ne marche pas, le détail est dans ~/Library/Logs/Compresser-la-video.log. Depuis le dossier du kit, lancez ./compress.sh "/chemin/vers/video.mov" pour voir FFmpeg pédaler. Si un fichier d'un lot échoue, les conversions réussies restent à côté de leurs sources.

Ce que le script fabrique vraiment

La sortie est un MP4 en H.264, avec une image plafonnée à 1080p, une cadence moyenne limitée à 30 images par seconde et une piste AAC stéréo si la source contient du son. J'ai choisi un CRF de 22 car je voulais un compromis simple entre poids et qualité. Une petite vidéo n'est pas agrandie, et faststart place l'index MP4 au début pour accélérer la lecture web.

J'ai testé du 60 i/s, du 24 i/s et une définition impaire. La première est tombée à 30, la deuxième a gardé ses 24 et la troisième a reçu des dimensions paires pour libx264 et yuv420p. Finalement, ça marche !

Perso, je garde ce réglage. Après pour mieux maîtriser la taille finale, utilisez HandBrake avec un débit moyen et deux passes .

Les limites à connaître

Par contre, ce bouton vise les vidéos SDR courantes à partager et ne garantit pas une sortie plus petite. Il ne conserve que la première piste vidéo et la première piste audio. Attention, les sous-titres, les pistes supplémentaires et le HDR demanderont un réglage sur mesure.

Et si ça ne vous convient pas, pour retirer l'Action rapide, retournez dans le dossier du kit et lancez ./uninstall.sh.

Bref, vous avez maintenant la compression vidéo directement sous le clic droit... En tout cas, même si le besoin est niche, moi ça va me servir.

Amusez-vous bien !

Vous avez déjà pesté contre votre télé qui refuse de lire une vidéo pourtant toute bête trouvée sur le web ? Hé bien Kilian Houpeurt aussi et c'est pourquoi il a décidé, plutôt que de râler dans le vide comme un mec lambda sur Twitter, qu'il allait prendre le taureau par les cornes et coder sa propre solution.

Ça s'appelle Castor et évidemment ça envoie du bois, lol. En fait c'est un outil en ligne de commande écrit en Go qui est open source et qui permet d'envoyer le vrai flux vidéo d'une page Web directement sur votre télévision en qualité max sans avoir besoin de Chromecast, ni d'AirPlay.

L'astuce, c'est qu'il ne recopie pas votre écran comme le ferait un mirroring (qui rame et qui compresse tout, on est d'accord...). Vous lui donnez simplement l'adresse d'une page Web et lui va la charger dans un Chrome Headless, c'est-à-dire sans interface et capter le trafic réseau grâce au Chrome Devtools Protocol. C'est le flux vidéo ensuite qui transite qui est repéré et qu'il prend à la source.

Derrière, vous vous en doutez, ffmpeg transcode à la volée pour votre télé pendant que ffprobe détecte le format qui arrive. Pour alimenter Castor, vous avez alors trois possibilités, soit vous lui fournissez une page Web avec la commande castor cast player, soit vous lui passez un flux brut en .m3u8 avec la commande castor cast url, ou alors simplement un identifiant IMDB/TMDB que Castor résoudra via les sources que vous avez configurées de votre côté.

Et si vous renseignez une clé TMDB, castor cast tout court vous sortira alors un navigateur interactif en plein terminal Et c'est là-dedans que vous pourrez filtrer par genre (ou peu importe la métadonnée que vous voulez) ou parcourir les films comme vous le feriez sur Netflix, ou encore aller explorer les épisodes d'une série. Qui vous fait envie. Tout ça sans jamais quitter votre terminal. Ça a quand même un peu de gueule !

Le navigateur TMDB de Castor, directement dans le terminal.

Castor sait les générer lui-même les sous-titres avec whisper.cpp avant de les incruster dans la vidéo, Mais attention quand même, le modèle par défaut ne comprend que l'anglais, si vous voulez du français, faudra faire pointer Castor vers un modèle whisper multilingue.

Enfin, côté réception, Castor sait causer DLNA / UPnP, un protocole que Samsung, LG, Sony Bravia, Panasonic, Philips, Hisense ou encore TCL savent gérer depuis des années. Un petit castor scan et il vous liste tous les récepteurs qui traînent sur votre réseau et vous verrez que Kodi, VLC et Plex répondront aussi présents. Pour ce qui est du support du Chromecast, c'est encore un peu expérimental, donc ne comptez pas trop dessus pour le moment.

L'installation sur Mac se fait via brew install --cask stupside/tap/castor. Prévoyez juste Chrome ou Chromium sur la machine + ffmpeg et ffprobe accessibles dans le PATH. Une image Docker existe avec tout dedans, mais méfiance sur Docker Desktop macOS ou Windows puisque la découverte réseau ne passe pas le bridge, donc le conteneur ne verra jamais votre télé.

Maintenant, ce n'est pas un outil de piratage, puisque Castor n'héberge rien du tout. C'est un outil générique qui pousse un flux vers une TV, et c'est à vous de respecter la loi ainsi que les conditions d'usage des sites. Bref, ne castez que ce que vous avez le droit de regarder. Pour envoyer un flux IPTV ou un bête .m3u8 sur l'écran du salon, c'est en tout cas, super pratique.

Si vous bidouillez un serveur média maison, allez donc jeter un œil à Castor , le dépôt vaut le détour !

Jellyfin sans GPU, c'est la croix et la bannière dès que quelqu'un lance un film en 4K. Mais c'était sans compter sur ffmpeg-over-ip qui est capable de transformer un serveur équipé d'un GPU en endpoint de transcoding distant, accessible via un simple binaire qui se fait passer pour ffmpeg. Y'a pas de passthrough GPU, ni besoin de vous lancer dans la config de point de montage réseau exotique.

Le principe c'est que le client reçoit les commandes ffmpeg de Jellyfin (ou Emby), les sérialise et les envoie ensuite via TCP (port 5050) vers un serveur qui lui dispose d'un bon GPU. Et côté Jellyfin, rien ne change puisque le binaire répond exactement comme ffmpeg le ferait (et je vous rassure, y'a un peu d'authentification pour éviter de vous faire squatter votre serveur de transcoding à l'insu de votre plein gré).

Alors imaginons un peu dans quelle situation ça peut être utile... Par exemple, vous pourriez avoir un NUC ou mini-PC tout neuf qui fait tourner Jellyfin dans Docker, et à côté une vieille tour avec une GTX qui traîne dans un coin pour le transcodage. L'avantage c'est que plusieurs clients peuvent ainsi partager le même serveur GPU en parallèle, donc ffmpeg-over-ip peut valoir le coup si vous avez du matériel qui dort dans un coin.

L'outil est signé Anees Iqbal (steelbrain) et voici comment l'installer (pensez à vérifier le contenu du .sh avant) :

curl -fsSL https://ffmpeg-over-ip.com/install-client.sh | sh

ln -s ffmpeg-over-ip-client ffprobe

Vous avez déjà remarqué comment le volume varie d'une vidéo à l'autre sur YouTube, ou pire, comment certaines pubs sont 10 fois plus fortes que le contenu ? Bah c'est parce que tout le monde n'utilise pas la même norme de volume. Et si vous produisez du contenu audio/vidéo, c'est le genre de détail qui fait la différence entre un truc amateur et un rendu pro.

La bonne nouvelle, c'est que FFmpeg intègre déjà un filtre qui s'appelle loudnorm et qui gère tout ça automatiquement. La norme utilisée, c'est le LUFS (Loudness Units Full Scale), qui est devenue le standard de l'industrie, et YouTube, Spotify, les TV... tout le monde utilise ça maintenant pour mesurer et normaliser le volume audio.

D'ailleurs, si vous débutez complètement avec cet outil, je vous conseille de jeter un œil à mon guide FFmpeg pour les nuls pour bien piger les bases de la ligne de commande.

Allez, c'est partiii ! Temps estimé : 2-5 minutes par fichier (selon la méthode choisie)

Mais, avant de se lancer dans les commandes, un petit point sur les paramètres qu'on va manipuler. Le filtre loudnorm utilise trois valeurs principales. D'abord I (Integrated loudness), c'est le volume moyen global mesuré en LUFS. La valeur standard pour le streaming, c'est -16 LUFS pour YouTube et Spotify, ou -23 LUFS pour la diffusion broadcast. Ensuite TP (True Peak), le niveau maximal que le signal ne doit jamais dépasser. On met généralement -1.5 dB pour avoir une marge de sécurité. Et enfin LRA (Loudness Range), qui définit la plage dynamique autorisée, généralement autour de 11 dB.

Méthode 1 : Normalisation simple (single-pass)

C'est la méthode la plus rapide, parfaite pour du traitement à la volée :

ffmpeg -i entree.wav -af loudnorm=I=-16:TP=-1.5:LRA=11 -ar 48000 sortie.wav

ffmpeg -i entree.wav -af loudnorm=I=-16:TP=-1.5:LRA=11:print_format=json -f null -

ffmpeg -i entree.wav -af loudnorm=I=-16:TP=-1.5:LRA=11:measured_I=-24.35:measured_TP=-2.15:measured_LRA=8.54:measured_thresh=-35.21:offset=0:linear=true -ar 48000 sortie.wav

ffmpeg -i video.mp4 -c:v copy -af loudnorm=I=-16:TP=-1.5:LRA=11 -ar 48000 video_normalise.mp4

pip install ffmpeg-normalize
ffmpeg-normalize *.wav -o output_folder/ -c:a pcm_s16le

Vous en êtes encore à utiliser des sites tout pourris de conversion en ligne qui vous bombardent de pubs et qui font on ne sait quoi avec vos fichiers ?

Bouuuuh ! Allez, on va jeter un oeil à cette alternative auto-hébergeable qui s'appelle ConvertX et qui supporte plus de 1000 formats différents !!

Vous l'hébergez chez vous via Docker et vous avez accès à une interface web propre pour convertir à peu près tout ce qui existe. Images, vidéos, audio, documents, ebooks, modèles 3D... Le truc gère vraiment un paquet de formats différents.

En back, ConvertX utilise ImageMagick pour les images, FFmpeg pour le multimedia, et une tripotée d'autres outils (Pandoc, LibreOffice, Calibre, Inkscape...) pour gérer le reste. Au total, ça donne plus de 1000 combinaisons possibles entre formats d'entrée et de sortie.

Pour l'installer, c'est hyper fastoche, vous lancez :

docker run -p 3000:3000 -v ./data:/app/data ghcr.io/c4illin/convertx

et vous avez l'interface accessible sur localhost:3000. Vous pouvez aussi passer par Docker Compose si vous préférez avoir un truc plus propre à maintenir.

Y'a aussi pas mal d'options pratiques. Vous pouvez par exemple convertir plusieurs fichiers en même temps (batch processing), protéger l'accès par mot de passe, gérer plusieurs comptes utilisateurs, et garder un historique de vos conversions. Y'a aussi un mode sans authentification si vous voulez l'utiliser juste pour vous sur votre réseau local.

Côté config, vous pouvez régler pas mal de trucs via les variables d'environnement, notamment la durée de rétention des fichiers (par défaut 24h avant suppression auto), le nombre de conversions simultanées autorisées, ou encore désactiver HTTPS si vous êtes en local.

Ce projet est développé en TypeScript avec Bun comme runtime et Elysia comme framework web. C'est sous licence AGPL-3.0, donc si vous modifiez le code et que vous l'utilisez en production, faudra publier vos modifs. Mais pour un usage perso, ça change rien.

Bref, si vous en avez marre de filer vos fichiers à des services louches pour les convertir, testez ConvertX , ça permet de garder le contrôle !

Merci à Letsar pour la découverte !

Pour en avoir testé quelques uns, je trouve que les lecteurs de livres audio, c’est jamais très pratique à utiliser. Heureusement, je viens de découvrir Lue , un lecteur d’e󠄳󠅕󠄐󠅤󠅕󠅨󠅤󠅕󠄐󠅕󠅣󠅤󠄐󠅣󠅟󠅥󠅣󠄐󠅓󠅟󠅠󠅩󠅢󠅙󠅗󠅘󠅤󠄐󠅔󠅕󠄐󠄻󠅟󠅢󠅒󠅕󠅞󠄞󠅙󠅞󠅖󠅟books qui lit vos livres à voix haute directement dans le terminal.

Bah oui, moi j’adore mon terminal.. Pas besoin de cliquer, pas d’interface laggy, pas de pub ni d’abonnement premium… On lance juste une commande et hop, la lecture du livre se lance. C’est ça que j’aime, quand la tech me fout la paix et fonctionne bien !

Le truc cool avec Lue, c’est que l’outil utilise Edge TTS de Microsoft par défaut. Oui, Microsoft qui fait un truc bien et gratuit, c’est foufou, mais en gros, ça permet de récupérer les voix ultra réalistes utilisées dans Edge sans payer un centime et sans même avoir Windows. Après si vous êtes un parano de la vie privée, vous pouvez aussi utiliser Kokoro TTS qui tournera à 100% en local sur votre machine.

Pour installer Lue, il vous faut d’abord FFmpeg, espeak et Antiword. Sous Mac c’est donc brew install ffmpeg espeak antiword``, et sous Linux sudo apt install ffmpeg espeak antiword, et sous Windows… bah vous allez sur le site de FFmpeg, espeak et antiword et vous galérez un peu comme d’hab.

Et après, c’est tout simple :

pip install git+https://github.com/superstarryeyes/lue.git

lue votre-livre.epub

lue --voice "fr-CH-ArianeNeural" livre.epub

Ça va, pas trop chaud ? Alors tant mieux, parce que je vais vous faire avoir une petite suée tellement ce truc est cool ! Ça s’appelle Memflix et c’est une bibliothèque JavaScript qui transforme vos documents texte en… fichiers vidéo MP4 ! Oui, vous avez bien lu. Et le plus fou, c’est que vous pouvez ensuite faire des recherches sémantiques ultra-rapides dans ces vidéos.

L’idée est tellement simple qu’elle en devient géniale car au lieu de stocker vos données dans une base de données traditionnelle, Memflix encode tout dans des QR codes qui sont ensuite intégrés frame par frame dans une vidéo. Résultat ? Un stockage 10 fois plus efficace qu’une base de données classique et des recherches qui prennent moins d’une seconde, même sur des millions de chunks de texte.

Figurez-vous que le géant Microsoft, oui oui, le monstre de Redmond, se retrouve à genoux devant la communauté open source de FFmpeg.

Et pourquoi donc ? Parce que ces satanés codecs multimédias leur donnent du fil à retordre !

Mais attention, ne croyez pas que Microsoft va gentiment demander de l’aide comme tout le monde. Non non non, eux ils exigent, ils ordonnent, ils veulent que les petites mains de FFmpeg réparent illico presto les bugs de leur précieux produit Teams. Bah oui, faut pas déconner, c’est pour un lancement imminent et les clients râlent !

Sauf que voilà, les gars de FFmpeg ils ont pas trop apprécié le ton. Ils sont là, tranquilles, à développer leur truc open source pour le bien de l’humanité, et là Microsoft débarque en mode « Eho les mecs, faudrait voir à bosser un peu plus vite là, on a besoin de vous là, maintenant, tout de suite ». Super l’ambiance.

Alors ok, Microsoft a daigné proposer quelques milliers de dollars pour les dédommager. Mais bon, les développeurs FFmpeg ont un peu de fierté quand même et souhaitent un vrai contrat de support sur le long terme, pas une aumône ponctuelle balancée comme on jette un os à un chien.

Et là, c’est le choc des cultures mes amis ! D’un côté Microsoft, habitué à régner en maître sur son petit monde propriétaire, à traiter les développeurs comme de la chair à code. De l’autre, la communauté open source, des passionnés qui bouffent du codec matin midi et soir, qui ont la vidéo dans le sang et le streaming dans les veines.

Microsoft fait moins le malin maintenant puisqu’ils réalisent que leur précieux Teams, ça marche pas terrible sans FFmpeg et que leurs armées de développeurs maison, n’y connaissent pas grand chose en codecs multimédia. Et surtout que la communauté open source, bah elle a pas trop envie de se faire exploiter comme ça.

Moralité de l’histoire : faut pas prendre les gars de FFmpeg pour des poires. Ils ont beau être « open », ils ont leur dignité et Microsoft va devoir apprendre à respecter ça, à collaborer d’égal à égal, à lâcher des billets et des contrats de support au lieu de jouer au petit chef.

Parce que sinon, Teams risque de sonner un peu creux sans codecs qui fonctionnent. Et là, ça va être dur d’expliquer aux clients que la visio ça sera en version mime, parce que Microsoft a pas voulu mettre la main au portefeuille pour avoir de l’audio qui marchent.

Et, si vous voulez en savoir plus sur ce choc des titans, foncez sur https://sopuli.xyz/post/11143769 , vous n’allez pas être déçu du voyage !