J'avais deux machines. Un ThinkPad — modèle 2015, deux cœurs, huit gigaoctets — avec une caméra Akaso branchée dessus. Et un MacBook faisant tourner OBS. Les deux sur le même réseau Tailscale.

La tâche était claire : faire passer l'image de la caméra par le réseau et l'injecter dans OBS.

Cinq obstacles sont apparus. Chacun dans une couche différente.

La première tentative fut la plus directe : capturer la caméra, compresser, envoyer en UDP.

Les paquets sont partis. Rien n'est arrivé.

L'UDP est le trafic que les pare-feu et les réseaux virtuels aiment le moins. Plutôt que de chercher où il se perdait, nous avons changé de route : TCP. SSH fonctionnait déjà sur TCP, donc ce chemin était ouvert.

Passage au TCP, ouverture d'un port, ajout d'une règle au pare-feu. Connexion refusée.

La raison était subtile. En me connectant en SSH, l'utilisateur avait les droits d'administrateur — mais la session n'était pas élevée. Sous Windows, ce n'est pas la même chose. La règle de pare-feu avait silencieusement échoué.

Au lieu de forcer le mur, nous l'avons entièrement contourné : un tunnel SSH. Nous avons fait passer la vidéo dans un canal qui fonctionnait déjà.

Le tunnel établi, ffmpeg a démarré et est mort au bout de quatre secondes.

L'erreur était explicite : tampon temps réel trop plein, image abandonnée.

Faute d'instruction contraire, la caméra était revenue à sa valeur par défaut : 3840×2160. Compresser de la 4K en temps réel n'est pas l'affaire d'un processeur bicœur de 2015.

La solution avait deux volets. Nous avons fixé la résolution à 1920×1080. Et nous avons déplacé la compression du processeur vers Intel Quick Sync — l'encodeur matériel intégré à la puce graphique.

La caméra savait produire du H.264 elle-même. Transmettons-le donc tel quel, sans y toucher. Charge processeur : zéro.

L'autre extrémité n'a pas pu le décoder. Le journal répétait une ligne : référence à un PPS 0 inexistant.

La caméra ne plaçait pas en tête de flux les en-têtes qui décrivent l'image — SPS et PPS. Un flux vidéo sans en-têtes est un texte sans alphabet.

Nous l'avons pris en MJPEG et réencodé via Quick Sync. Une étape de plus, mais les en-têtes à leur place.

Tout fonctionnait. L'image est arrivée. Puis elle a disparu.

Vérification : le processus que j'avais lancé n'existait plus. Le journal d'erreurs était vide. Le programme n'avait pas planté — il avait été tué.

La cause, c'était SSH lui-même. Sous Windows, une session SSH rattache les processus qu'elle démarre à un objet de tâche ; quand la session se ferme, les enfants partent avec. En coupant ma connexion, je coupais aussi la caméra.

Nous avons transformé la diffusion en tâche planifiée. Elle ne dépend plus d'une session : elle vit seule et se relance après chaque coupure.

L'image est arrivée. Assis à mon bureau, je me suis vu sur mon propre écran — mais cette image était sortie de l'ordinateur portable à côté de moi, avait traversé un tunnel chiffré, et était revenue.

Et voici la vraie découverte : un portable bicœur, vieux de dix ans, compresse de la vidéo 1080p30 pendant que son processeur reste presque inactif. Grâce à Quick Sync. Je croyais cette machine faible. C'étaient mes réglages qui l'étaient.

Aucun des cinq obstacles n'était une insuffisance matérielle. Tous les cinq relevaient de la configuration, du protocole et du comportement du système d'exploitation.

Si j'avais acheté une machine neuve et puissante, les cinq seraient apparus à l'identique.

Construire un système, ce n'est pas acheter des pièces puissantes. C'est découvrir, une par une, pourquoi les pièces refusent de se parler.