2026 : file de transcodage FFmpeg sur Mac Mini loué — disque temporaire, parallélisme et backoff pour la nuit

TMPDIR, parallélisme, 7×24 ou nuit, launchd ou GNU parallel, backoff. Liens : blog, aide, matrice 7×24, FAQ disque APFS.

Pourquoi la file FFmpeg casse l’expérience sans règles explicites

1. Scratch au mauvais endroit. Écrire segments et fichiers temporaires sous ~/Library ou le volume du système partagé avec d’autres locataires amplifie la latence aléatoire et les snapshots APFS coûteux.
2. Parallélisme aveugle. Multiplier les ffmpeg sans tenir compte des filtres, du débit NVMe et du budget thermique déclenche du throttling silencieux : les durées médianes explosent sans erreur explicite.
3. Reprises brutales. Relancer immédiatement après une erreur réseau ou un code 137 sans jitter martèle la source et masque la cause racine dans les journaux.

Matrice décisionnelle : où écrire, combien de jobs, quel outil de file

Croisez avec le profil de nœud et la matrice batch CPU et mémoire pour les slices longue durée.

7×24 versus fenêtre nocturne : launchd, cron et paramètres de file

Le 7×24 tient si les paliers disque du FAQ APFS et la matrice 7×24 protègent le jour interactif. Fenêtre nuit : StartCalendarInterval et ThrottleInterval dans un plist launchd ; crontab avec flock si le batch dépasse l’aube.

GNU parallel : parallel -j 2 --delay 2 --joblog ~/logs/ffmpeg-job.log ... ::: liste.txt. launchd : Nice positif, ProgramArguments vers script enqueue pour survie au reboot.

Parallélisme ffmpeg : threads, jobs simultanés et filtres

Un gros 4K par NVMe ; deux jobs après stabilité CPU et thermique. -threads près des cœurs performance si -filter_complex domine ; -map explicites, peu de copies RAM/disque.

Multi-équipes : fichier flag de plafond CPU lu par le script, aligné sur la matrice 7×24.

Liste de paramètres de backoff après échec

• Délai initial : environ soixante secondes avant la première reprise après erreur réseau ou timeout.
• Exponentiel : doubler jusqu’à un plafond de dix minutes pour ne pas bloquer la file indéfiniment.
• Jitter : ajouter jusqu’à trente pour cent d’aléa pour éviter l’effet troupeau sur la source.
• Budget d’essais : trois à cinq tentatives puis escalade humaine et entrée dans un fichier dead-letter avec checksum partiel.

Louer ou acheter

Codecs et fenêtres encore mouvants → louer garde l’option ; acheter si le TCO d’un transcodeur saturé 24/7 sur douze à dix-huit mois dépasse clairement un abonnement équivalent SSD.

Runbook : six étapes pour industrialiser la file

1. Inventaire. Lister chaque profil d’encodage avec durée médiane, taille source et caractère idempotent.
2. Scratch. Créer un répertoire dédié, permissions restrictives, quota documenté ; exporter TMPDIR dans le plist ou le service.
3. Paliers. Brancher une sonde df ou APFS : pause enqueue sous le seuil défini dans la FAQ disque.
4. Concurrence. Fixer jobs max et threads ffmpeg ; valider une charge de trente minutes en SSH.
5. Minuteur. Déployer launchd ou cron avec flock ; vérifier un seul run actif par créneau dans les logs.
6. Backoff. Intégrer le script de reprise avec jitter et plafond ; alerter au-delà du budget d’essais.

Repères citables pour cadrer exploitation et astreinte

• Quinze pour cent d’espace libre ou cinquante gigaoctets minimum : règle de garde initiale avant pause des nouveaux jobs sur tenant partagé.
• Deux processus ffmpeg simultanés maximum sur un M4 avec filtres lourds tant que la mémoire résidente totale dépasse vingt gigaoctets avec autres services.
• Dix minutes de plafond de backoff et trente pour cent de jitter : compromis observé entre réactivité et protection des sources.

Foire aux questions