dms : le serveur DLNA qui se lance depuis un terminal et transcode pour le Chromecast
Un serveur multimédia numérique UPnP DLNA qui inclut un transcodage vidéo de base. Testé sur un téléviseur Panasonic Viera, plusieurs applications Android UPnP et Chromecast.
En bref
- De quoi s’agit-il ?
- Un serveur multimédia UPnP DLNA en Go, sans interface d'administration, qui sert le système de fichiers au réseau local, ajoute des flux transcodés à la demande et délègue tout le travail lourd aux outils ffmpeg.
- À qui s’adresse-t-il ?
- Distribué sous BSD-3-Clause, dms peut être embarqué, modifié et redistribué en conservant l'avis de copyright, sans garantie de l'auteur. Il convient à qui veut un serveur DLNA piloté au terminal, sans interface web ni base de données ; il ne convient pas à qui cherche des réglages de transcodage fins, le README n'en documentant aucun.
- Puis-je l’utiliser commercialement ?
- Oui. BSD-3-Clause est une licence permissive : vous pouvez utiliser, modifier et vendre un logiciel qui en dépend, à condition de conserver les mentions de droit d’auteur et de licence.
- Est-il encore maintenu ?
- Oui. Les derniers commits datent d’il y a 34 jours.
- En quel langage est-il écrit ?
- Principalement Go, d’après les statistiques de langage de GitHub.
Ces réponses reposent sur les données GitHub du projet (dernière synchronisation le 14 septembre 2026) et sur notre analyse. Elles ne constituent pas un avis juridique.
ANALYSE OPEN SOURCE APPROFONDIE
Un serveur DLNA qui vit dans un terminal
dms est un serveur multimédia UPnP DLNA écrit en Go, qui se lance depuis le terminal et sert le contenu directement depuis le système de fichiers : le répertoire de travail courant, ou le chemin passé au démarrage. Aucun écran de configuration n'est mentionné ; le README décrit un binaire qui tourne et diffuse, point.
La découverte repose sur le composant SSDP, qui diffuse et répond sur toutes les interfaces réseau disponibles. Les clients du réseau local voient donc le serveur sans aucune déclaration préalable. La description du projet annonce les bancs d'essai : un téléviseur Panasonic Viera, plusieurs applications UPnP Android et un Chromecast. Le dépôt, au 29 août 2026, affiche 748 étoiles, 114 forks et 24 tickets ouverts, sous licence BSD-3-Clause.
Le PATH décide de ce que le serveur sait faire
dms n'embarque aucun moteur multimédia : il s'appuie sur des commandes externes, qui doivent figurer dans le PATH donné au processus. ffprobe ou avprobe lisent les métadonnées comme le débit et la durée, ffmpeg ou avconv assurent le transcodage vidéo, ffmpegthumbnailer produit les vignettes pendant la navigation.
La règle de dégradation est énoncée sans détour : si une commande manque, la fonctionnalité qui en dépend est désactivée, et le serveur continue de tourner. Une installation minimale sert donc les fichiers bruts seuls, tandis qu'un système où la famille ffmpeg est complète gagne transcodages et vignettes. Ce choix rend le comportement prévisible, au prix d'une variance d'une machine à l'autre que le README n'aide pas à diagnostiquer.
Des fichiers bruts aux transcodages pour Chromecast
Le serveur annonce et sert les fichiers tels quels, et y ajoute, quand il le peut, des flux transcodés alternatifs. Les deux exemples du README donnent la mesure : du mpeg2 au format PAL-DVD, codec de prédilection des téléviseurs anciens, et du WebM pour le Chromecast. Le client reçoit donc un choix entre l'original et une version adaptée à son matériel.
Les vignettes complètent l'expérience de navigation, produites par ffmpegthumbnailer quand l'outil est présent. Ce que le README ne documente pas : les paramètres de qualité des transcodages, la liste des formats d'entrée reconnus, ni la règle qui décide quand un flux alternatif est proposé. Les liens vers CHANGELOG.md et FAQ.md, posés en tête du README, sont alors les recours indiqués.
Les flux vivants, par délégation à une commande externe
Au-delà des fichiers, dms sait servir des flux dynamiques, générés à la volée avec l'aide d'une application externe, ffmpeg servant d'exemple. Le cas d'usage cité est un flux RTSP en direct, typique d'une caméra, mis à disposition des lecteurs DLNA du foyer.
Le README se borne à établir l'existence de la fonction et sa dépendance à un programme auxiliaire : ni la syntaxe de déclaration du flux, ni le protocole attendu entre dms et la commande, ni le comportement face à plusieurs clients simultanés ne sont décrits dans la partie consultée. La FAQ liée depuis l'entête devient ici le document à lire avant toute mise en production d'un tel montage.
Un service FreeBSD écrit noir sur blanc, les autres systèmes à la main
La seule intégration système documentée concerne FreeBSD. Le dépôt fournit un fichier de service en helpers/bsd/dms, à installer dans /etc/rc.d ou /usr/local/etc/rc.d ; /etc/rc.conf reçoit dms_enable="YES", et de façon optionnelle dms_root pour le répertoire multimédia et dms_user pour l'utilisateur d'exécution.
Pour les autres systèmes, le README s'arrête au lancement manuel : go install github.com/anacrolix/dms@latest, en supposant Go et GOPATH déjà en place, puis "$GOPATH"/bin/dms. Rien sur systemd, rien sur les règles de pare-feu qu'exige la découverte SSDP, rien sur la limitation à une interface réseau quand la machine en porte plusieurs, le composant SSDP écoutant toutes les interfaces par défaut.
Des versions rares et un appel au financement
Le README s'ouvre sur une demande de financement pour poursuivre le développement, via GitHub Sponsors, avec invitation à passer par la liste des tickets pour toute proposition précise. Ce ton direct annonce l'état du projet : maintenu, mais sans abondance de ressources.
Le rythme des versions le confirme : v1.6.0 en mai 2023, v1.7.2 en juillet 2025, v1.8.0 le 28 juillet 2026, soit des publications espacées d'un à deux ans, la dernière coïncidant avec le dernier push du dépôt. Pour un serveur DLNA, domaine où les protocoles bougent peu, cette lenteur n'est pas rédhibitoire ; elle demande en revanche d'accepter que les corrections passent par le dépôt master entre deux versions.
Conclusion éditoriale
Distribué sous BSD-3-Clause, dms peut être embarqué, modifié et redistribué en conservant l'avis de copyright, sans garantie de l'auteur. Il convient à qui veut un serveur DLNA piloté au terminal, sans interface web ni base de données ; il ne convient pas à qui cherche des réglages de transcodage fins, le README n'en documentant aucun. Avant d'en faire son serveur de salon, le test tient en trois gestes : go install github.com/anacrolix/dms@latest, vérifier que ffmpeg et ffmpegthumbnailer répondent dans le PATH, puis lancer dms dans le dossier multimédia et chercher le serveur depuis le téléviseur, la découverte SSDP devant apparaître d'elle-même.
Notes de la communauté