J'ai fait un projet qui permet de streamer des films depuis ma Freebox. Mais j'utilise un petit serveur dédié au streaming:
Il y beaucoup d'objections à faire ce que j'ai fait:
- La Freebox est visible depuis un media center via SMB
- La Freebox Ultra permet de lancer des VM
- Tu as déjà un Nas avec Jellyfin et NVENC
Mais mon problème, c'est que non seulement le media center ne tient pas si le flux est trop gros, car ce protocle repose uniquement sur le débit du réseau lui même. Comment plafonner ce débit si ce n'est la compression vidéo ?
De plus, j'ai passé des années à déplacer les mêmes fichiers d'une machine à l'autre pour pouvoir les regarder. Cette fois j'ai arrêté de les copier...
Le problème n'était pas le stockage, c'était la copie
J'ai une Freebox Ultra que j'aime beaucoup, avec un disque plein de vidéos et un serveur FTP activé dessus. Ça marche aussi sur une Revolution, et probablement sur les autres modèles, parce que le FTP est là depuis toujours.
Avant ça j'avais déjà monté une box de streaming à partir de mon NAS : Jellyfin, GPU passthrough sur une Nvidia Quadro P1000 pour l'encodage, le confort complet. Mais le NAS impose une copie des fichiers à chaque fois, et comme je passe par Nextcloud, ça veut dire pousser 40 Go avant de pouvoir lancer un film. Le vrai coût du setup, ce n'était pas le GPU, c'était l'aller-retour.
Pourquoi je ne fais rien tourner dans la box
La Freebox sait faire tourner des VM. Donc l'idée évidente, c'est d'y coller le serveur média et de fermer le sujet.
Sauf que je n'ai aucune envie de charger la machine qui fait tenir mon réseau debout. Elle a un job et elle le fait bien : servir des octets.
Et il y a un deuxième argument, qui compte au moins autant à mes yeux. Le jour où je veux accéder à ma collection depuis l'extérieur, je préfère largement ouvrir sur une machine que je peux jeter et reconstruire en dix minutes, plutôt que sur mon routeur. Une box compromise, c'est tout le réseau derrière. Un proxy compromis, c'est un conteneur que je repars de zéro.
Donc j'ai posé un proxy en front, et j'ai réparti le travail :
- la box lit le disque et envoie des plages d'octets en FTP, rien de plus
- le proxy fait tout le CPU : probe, transcodage H.264, découpage HLS
- le navigateur reçoit un flux léger, calibré pour du wifi d'hôtel ou de la 4G
Le vrai point dur : ffmpeg ne sait pas lire du FTP
Toute l'architecture découle de là. ffmpeg ne parle pas au serveur FTP de la box, donc je lui présente un proxy loopback en HTTP qui répond en 206 Partial Content avec un Content-Length exact, et qui traduit derrière les Range HTTP en REST/RETR sur le FTP.
Résultat, la source devient seekable.
Sauter à 1h20 d'un remux de 60 Go ne télécharge que cette région du fichier, jamais le reste. Si je passais un pipe à ffmpeg à la place, tout le design du seek s'effondre.
Ce que ça donne à l'usage
C'est hyper fluide. J'ai vraiment l'impression d'être sur YouTube, sauf que c'est ma collection, que rien ne part chez personne, et que les vignettes sont des frames extraites du milieu de mes propres fichiers plutôt que des jaquettes tirées d'un catalogue en ligne.
Le projet est en Go, sous licence MIT, et se lance en Docker :
git clone https://github.com/aluzed/freebox-proxystream.git
cd freebox-proxystream
cp .env.example .env
docker compose up -d
Un détail contre-intuitif avant de choisir votre machine : un Raspberry Pi 5 est moins bon qu'un Pi 3 ou un Pi 4 ici, parce que le BCM2712 a perdu l'encodeur H.264 matériel.
La génération qui a perdu l'encodeur a perdu le job. Sur x86 ou Apple Silicon, vous avez le choix entre libx264 en soft et NVENC, VAAPI, Quick Sync ou VideoToolbox en hardware.
Le dépôt est ici : freebox-proxystream.
C'est un projet communautaire, sans API privée ni rétro-engineering, et Free n'a rien à voir avec.
