Un Raspberry Pi, vrai serveur multimédia, sauf en 4K

Un Raspberry Pi 4 fonctionne depuis des mois sur une étagère et diffuse une véritable bibliothèque depuis un disque USB. Le verdict est partagé, et il ne se situe pas là où les guides d’achat le placent. L’ensemble dépend d’une interrogation unique : quelle part de votre collection doit être réencodée avant d’atteindre un écran ?

La carte d’où proviennent ces chiffres

Les interfaces de codec diffèrent selon les fabricants, et parfois entre deux noyaux du même fabricant ; considérez donc ce qui suit comme le compte rendu d’une configuration particulière :

1. Un Pi 4 modèle B avec 4 Go de mémoire, sous Armbian 64 bits basé sur Debian 13.
2. Démarré depuis un SSD USB, avec l’emplacement de carte vide.
3. Une bibliothèque sur un disque externe NTFS : 2 276 fichiers de films, 1 583 fichiers d’épisodes et 44 documentaires.

Un NAS, un boîtier Rockchip ou un Odroid demande sa propre mesure avant que vous vous fiiez à l’un de ces chiffres. Effectuez vos propres mesures plutôt que d’extrapoler.

Le circuit possède un seul encodeur, et c’est le H.264

Le BCM2711 prend en charge l’encodage et le décodage matériels du H.264 par l’interface V4L2 M2M. Ce circuit ne dispose d’aucun VAAPI, quoi que laisse entendre une coche « transcodage matériel » dans un tableau comparatif. Le HEVC se limite au décodage, et ce décodeur sans état est piloté par l’API V4L2 Request, sur son propre nœud, ce qui pénalise sensiblement le débit. La même charge de 30 secondes mesure l’importance de cet écart :

Source	Chemin	Rythme mesuré
H.264 1080p	décodage V4L2, encodage V4L2	environ 2x le temps réel
HEVC Main 1080p	décodage logiciel, encodage V4L2	1,14x
HEVC Main 1080p	décodage Request, encodage V4L2	1,78x
HEVC Main10	décodage Request, détuilage, encodage V4L2	1,59x
4K Dolby Vision	logiciel de bout en bout	0,05x

Toute valeur supérieure à 1,0 signifie qu’une seconde de film nécessite moins d’une seconde de traitement. La ligne H.264 est la plus confortable, avec environ 403 Mio de mémoire et la carte à 65,2 °C, et placer le décodeur Request devant le même encodeur a fait passer le HEVC de 1,14x à 1,78x, ce qui constitue tout l’argument en faveur du chemin sans état. La dernière ligne sert d’avertissement : deux secondes d’image pour quarante secondes d’horloge, un écart qu’aucun réglage ne rattrapera.

Ce que fait le serveur quand la carte ne suit plus

Une session qui prend sans cesse du retard est pire qu’une session qui s’arrête, car le spectateur subit une minute de mise en mémoire tampon pour aboutir à la même conclusion. Le serveur surveille donc son propre rythme : un encodage dispose de 45 secondes de grâce, puis doit maintenir 0,6 du temps réel. En dessous, la session se termine avec playback.transcode.too_slow, et le client l’explique en une phrase.

Le coût qui n’apparaît dans aucun comparatif

La lecture d’un fichier représente également un travail. Construire la carte des images clés d’un film HEVC de 3,3 Go sur ce disque USB NTFS a demandé 120 secondes, alors que la requête qui attend cette carte dispose de huit secondes ; elle abandonne donc et la session transcode un fichier que le client aurait pu lire tel quel. Une fois la carte construite discrètement en arrière-plan, la session suivante de ce film devient une copie directe dont la recherche fonctionne correctement.

Des sous-titres tirés de la parole, sur le même matériel

Trente secondes de dialogue en anglais ont demandé environ 114 secondes de transcription, avec un pic de 755,5 Mio sans fichier d’échange, et le résultat comptait 14 répliques avec 12,96 pour cent d’erreurs de mots par rapport au sous-titre de référence ; les mots restent exploitables, même si le minutage se relâche sur une carte aussi modeste, et c’est pourquoi la génération de sous-titres devrait revenir à la machine de la maison qui dispose de capacité disponible.

Alors, est-ce suffisant ?

C’est suffisant lorsque la majeure partie de votre collection se lit déjà telle quelle, situation que l’on oublie souvent au moment de comparer des puissances de transcodage. Un client natif accepte un MKV contenant une vidéo HEVC et une piste sans perte tel qu’il est enregistré, et le serveur passe sa soirée à transmettre des octets : un Pi 4 assure cette tâche toute la journée sur une liaison gigabit, pour quelques watts. Les cinq situations qui déclenchent un réencodage méritent une lecture avant tout achat de matériel, car quatre d’entre elles relèvent de choix que vous pouvez modifier.

La configuration devient insuffisante avec la 4K et dès le troisième flux simultané à convertir. Elle ne résistera pas davantage avec la carte plus récente, puisque le BCM2712 du Pi 5 a abandonné l’encodeur H.264 matériel et que chaque transcodage retombe sur le processeur.

Questions fréquentes