Bonjour à tous,
Je viens de m’inscrire et je sens que la progression sur l’univers Raspberry va être grande ici !
Il y a moins d’un mois, je ne connaissais pas du tout le Raspberry. C’est au cours d’une pérégrination sur YT que j’ai entendu parler pour la première fois de la framboise. En fait, je cherchais à remplacer mon vieux pc portable par quelque chose de performant et de…petit. J’étais de plus en plus tenté par un mini PC sans vraiment me décider. Et donc, miracle : un nano ordinateur petit mais performant existe !
Ni une ni deux, je me renseigne et décide rapidement de me procurer le dernier modèle. Et oui, j’ai eu la chance de ne pas devoir attendre, du coup, entre ce modèle et le précédent, comme ont dû faire beaucoup de propriétaire des PI antérieurs.
Donc tout est installé et les performances sont au rendez-vous.
J’aurai plein de question pour finaliser cette installation. Mais je vais attendre que ma période d’approbation soit moins importante pour ça.
Je dois aussi préciser que je suis sous linux depuis des années mais que je n’ai jamais vraiment utilisé le terminal. J’ai décidé de m’y mettre et d’apprendre les lignes de commandes de base.
Je compte également monter une webradio avec un serveur dédié pour ça. J’hésite à installer sur mon vieux pc les logiciels (Icecast avec Butt) ou bien le faire sur mon PI à cause de la sécurité qui doit être maximale.
Pour ta Web Radio, si tu veux, j’ai déjà un serveur publique dédié et je peux ajouter ta « chaine » à mon serveur, si ton but est « sérieux ». Mon système est monté sur un dédié en France, avec le serveur Shoutcast. Tu peux voir ma radio publique ici ; https://radio.levelkro.net .Elle est up depuis une dizaine d’année.
Petit rappel, un RPi est un processeur ARM, alors il faut que les apps soit compatible ARM (x64 vu que tu as surement un RPi 5).
Salut levelKro,
Merci beaucoup pour ta proposition, mais il se trouve que c’est un projet de webradio de musiques médiévales, donc pas raccord avec ce que tu diffuses et puis je préfére une autonomie complète, c’est pour ça que je n’ai pas choisi de services comme radioking et autres par exemple.
Mais dans la mesure où tu as ta webradio en place, je pense que tu es une mine d’or pour moi en terme de renseignements techniques.
Si tu veux bien me filer un coup de main bien sûr.
Salut LevelKro,
Je viens de lire deux trois petites choses sur le site de Icecast et notamment de point de montage, en expliquant que si un auditeur met en pause son flux, les autres auront leur flux coupés aussi.
C’est bien ça ou j’ai mal lu ?
Mon flux marche, c’est que sur le site, du au HTTPS, des fois, le certificats n’est pas accepté pour le flux (peut pas croiser un flux non sécurisé sur une page sécurisé). Je suis a régler ça et actualiser la playlist.
Icecast est basé sur Shoutcast, c’est un serveur de partage multimédia. Je ne connais pas Icecast, ayant mes licences sur Shoutcast et une bonne expérience avec.
Un serveur ne devrait pas couper le stream sur les autres client, c’est illogique. Je crois plutot que l’avertssiement est sur la gestion du stream pour le client.
En effet, lors d’une connexion au server, le client récupère le stream depuis un temps X, une entête de format est ajouté. Le client, si il pause, il interrompt la transmission, mais en « dépause », il va continuer sur le stream ou il a laissé, et non ou il serais rendu.
Alors par exemple, si deux utilisateurs écoute en même temps la radio (et s’y connecte), ils auront une écoute équivalente en temps réel (1-5 secondes possible du a divers facteurs du réseau). Si l’un deux, pause, durant 10 minutes, et continue la lecture, il sera alors décalé de 10 minutes avec l’autre. Pour cette raison un stop serais mieux adapté pour arrêter la lecture.
Mais cette chose dépend plus du client de le serveur, car il a un « buffer time » qui a une limite. Par exemple avec Shoutcast, c’est 15 secondes de buffer par défaut. Ce qui fait que le client a toujours 15 secondes préchargé en mémoire, pour éviter la coupe en cas de perte du débit momentané. Ceci est comme le buffer des lecteurs CD portable, qui ce servait de ça pour leur « anti-choc ».
Icecast peut faire différent, en ajoutant un plus grand buffer ou une capacité d’enregistrement du stream, permettant la navigation dans ce dernier. Mais comme je te dis, je connais Icecast que de nom, alors cette fonction n’existe peut-être pas.
J’utilise Shoucast depuis une vingtaine d’année, bref depuis sont arrivé sur le marché, à l’époque de Winamp qui était avec Nullsoft. J’ai donc créé plusieurs choses avec depuis les années, et j’ai payé ma licence MP3 requise. J’ai fais des radio communautaire, un streaming de vidéo, et actuellement, depuis près de 10 ans, une radio automatisé en lecture indépendante avec SC_trans (Transcoder). Je connais bien les limites et potentiel de mon serveur, la dernières version permet l’ajout de plusieurs canaux sur le même serveur, ce qui fait que j’ai en fait deux radio, plus 2 autres pour le live.
Merci pour tes réponses détaillées. Pour l’automatisation (c’est ce que je souhaite faire), quel logiciel tu conseilles ?
Est-ce que tu conseillerais une carte son dédiée ? Et niveau sécurité du serveur, tu as dû blinder pas mal, non ?
Le plus simple sera le mieux, alors il faut qu’il soit en ligne de commande.
Pour Shoutcast et tous mes serveurs/services, je roule en X86 (64bits), alors mon choix est déjà plus grand que sous ARM (32-64bits). Vu que je désirais resté dans l’écosystème Shoutcast, j’ai opté pour le malheureusement obsolète SC Transcoder.
Juste te dire, l’exécutable n’est pratiquement pas trouvable. J’ai des copies qui date de longtemps. Le projet SC Transcoder (sc_trans) a été abandonné voila très longtemps.
Alors je suppose que FFMpeg serait l’alternative la plus simple. Tu devra créer une playlist et l’envoyer sur le serveur Icecast. Le site de Icecast peut t’aider à trouver des programmes pour faire ça aussi, j’imagine (sur leur forum surement).
Pour limiter l’usage du CPU, car l’encodage peut être fort sur l’usage du CPU, je te conseil de préformater tes fichiers source dans le format de sortie désiré. Par exemple en MP3, Stéréo, CBR, 128kbps 44.1kHz. Évite les VBR, qui demande un ajustement audio constant du transcodeur. Tu n’auras pas de différence entre le Stéréo et le Stéréo-Mix, qui apporte peut de différance au décodage.
Exécuter le Trancodeur sur le même système que le serveur évite le latency et les problèmes causé par le réseau. Pour une seul radio bien configuré, tu pourras avoir une bonne radio.
La bande passante est de 10~15Kb/s (pas kbps) pour du 128kbps Stéréo 44KHz MP3, avec un retour du client entre 1 et 5 k/s (ping, pong). La charge CPU, basé sur des tests d’époque, sur un 233MHz Pentium était de 0.5% à 1.5% par client, négligeable.
Mais la gestions des clients peut devenir plus intense si plusieurs connexions/déconnexions s’effectue. Sur un RPi vu que le transcodeur serais dessus, je te dit que la limite serais de 16-32 clients pour les RPi 3 et moins, et 32-64 pour le RPi 4 et mieux.
Autre fait a noter, comme tu as vu, mon site n’a pas démarré le stream. Aujourd’hui les pages doivent être en HTTPS, dont un certificat SSL est requis. Sur internet c’est simple de gérer ça, avec Let’s encrypt qui en fournis des gratuit, valide 3 mois et renouvelable. Le problème rencontré est que le serveur doit redémarrer et prendre en charge le nouveau certificat créé, pour ça que la lecture n’a pas démarré. Le certificat était invalide pour le SSL du streaming, mais pas de la page Web.
Alors si tu l’affiche publiquement, tu devras opter pour cette capacité. Je ne sais pas si Icecast le supporte, mais Shoutcast oui depuis une ou deux versions.
Le support est arrivé en fait dès la version 2 de Shoutcast, mais a été réellement utilisable depuis que la version 2.5 ou 2.6 je crois. Je roule actuellement sous 2.6.1.777.
Mais si tu veux que du local, faudra pensser a faire l’appel du site uniquement via le HTTP non sécurisé.
J’ai des applications sous Windows pour le streaming. VirtualDJ est compatible avec Shoutcast et Icecast. SAM Broadcasting est un excellent outile radio. FFMpeg est en ligne de commande, mais avec VLC il est possible, je crois d’arriver à streamer. OBS (et clones) ne serais pas compatible, étant axé vidéo. Winamp possède un plugin pour le Streaming (DSP Shoutcast de mémoire).
J’ai mis en ligne l’ensemble de mes fichiers sources pour Shoutcast, bon je sais c’est pas ce qu’il te seras le plus utile, vue que rien ne marcherais sous RPi (ARM), mais si tu veux faire des tests ou si tu songe à y inclure un PC sous WIndows/Linux, comme faire du live, tu aura une bonne base.
Le serveur est un dédié sous Debian 10, avec sécurité standard (passwords) et un Firewall. Le shoutcast fournis une section admin gérer par HTTP Auth avec un user/pass, le Streaming, étant différent de la version 1 et 2 de Shoutcast, il possède la capacité de gérer le deux, la version 1, avait un serveur dédié à un seul stream, alors ce n’était qu’un password, mais avec le multiples stream, il y a le user qui peut entrer en compte pour les streaming Version 2 uniquement.
Après le serveur Shoutcast permet de gérer les ban list. J’ai acuellement 3 IPS banné car c’était un re-streamer. Avec les logs il serais possible de créer un moyen d’analyser et déterminer les comportement abusif (Mass connect/déconnect, tentatives de DDos). Perso j’ai jamais eu de problème, car j’ai un paramètre qui termine les connexions si il ne télécharge pas durant 60 secondes, même chose pour la source, évitant les kicks des sources pour les empêcher une reconnexion. Mais il y a d’autres paramètres possible, comme la validation des user agent, liste d’IP réservé, etc…
Avec Icecast, tu devrais avoir quelque chose proche de ça. Après, je crois qu’il ont leur propre méthode d’identification, différent de Shoutcast, alors c’est quelque chose à regarder.
Je pense utiliser OGG plutôt que le MP3. Mais comme je ne connaissais pas le paramètre d’encodage CBR,VBR, etc, je suis allé jeter un oeil ici. Apparemment, tantôt l’un est bon, tantôt l’autre…
Pour moi, dans la mesure ou j’ai un NVMe SSD de 1T, le stockage n’est pas un point important, ce n’est pas pour ça que je choisirai plutôt Orgg que le MP3.
A propos de CPU, tu penses qu’utiliser un PI5 pour cette webradio en tant que serveur c’est intéressant ou pas ?
J’aurai qu’un seul stream et ce sera de l’automation.
VirtualDj n’est pas compatible Linux apparemment SAMBroadcaster non plus mais y a un équivalent linux : OBS studio. J’ai vu une page d’installation sur debian-facile…
Au niveau software, j’ai quasiment tout je crois. Il me « reste » plus qu’à mettre le site en ligne et payer la SACEM et le SPRE… Mais j’en suis pas encore là.
Le OGG est moins populaire, c’est le format sans licence avec Shoutcast, mais le MP3 est plus compatible avec les appareils. Deplus ma collection de musique est tout en MP3, alors plus simple a gérer.
Le VBR et CBR sont important, c’est le Bitrate. VBR est variable (Variable Bit Rate), et selon les applications, le temps peut être tronqué ou allongé. Le CBR (Constant Bit Rate) a un niveau de Bitrate égaux peut importe la position dans la piste. C’est le format le plus compatible car il fournis une valeur constante d’échantillonnage et les applicable ce basant la dessus pour déterminer la fin de la piste n’aura pas de problème.
Certaines applications détermine la duré, donc la fin, ce basant sur un calcul du Bitrate et de la taille du fichier. Avec certains morceaux, la fin peut être coupé avant, comme dans d’autres cas il aura un silence. De plus, ça demande une conversion du Transcodeur pour ajuster en CBR sur le stream. Enregistré un MP3 en VBR 128kbps par exemple permet au fichier d’enregistrer les informations entre 0 et 128kbps, tandis qu’un CBR en 128kbps va donner toujours 128kbps par segment. L’avantage du VBR est la taille réduite, au détriment de la qualité. Tandis que le CBR sera plus gros, mais avec un son plus égales (qualité) d’un bout à l’autre. Le kbps va dépendre de la « charge » audio, la profondeur (de qualité) du morceau. Passer de faible valeur a haute valeur (et inversement) peut causer une déformation audio (l’effet de numérisation genre) plus fréquents selon la qualité du lecteur.
Dans mes explications, je ne songeait aucunement à l’espace requis, pouvant être contourné facilement et ayant pas d’impact sur l’écoute. Mais la qualité des fichiers est importantes. L’idées est de préparer les fichiers pour que le Transcodeur et le Serveur ai un minimum de travail à faire et ainsi éviter la surcharge du CPU.
Le système Shoutcast étant créé en fin "90, début 2000, il marche facilement sur de petite configurations. Après c’est pour te donner des détails pour que tu puisse comprendre que cette utilisation, même en background, est quand même à prendre en compte.
Comme chez nous, je fais des fois du show live de DJ. Alors j’ai un PC dédié au mixage, et un autre à l’encodage et streaming sur le serveur. Comme ça je garde un système réactif pour le mixage et un autre qui aura toute la capacité pour encoder et streamer, sans avoir d’effet de l’un sur l’autre.
J’ai pourtant un Ryzen 16 coeurs avec 32GB de ram, alors je pourrais facilement faire le tout sur le même système. Mais il est préférable d’avoir deux système dans cette config, en cas que la station de DJ ai un problème technique, il est facile de passer a l’autre sans trop de perte pour les clients.
Mais en contexte d’automatisation, il est préférable, comme tu semble vouloir faire, un seul système radio. Tu évite le transfert du Transcodeur au Serveur, étant en local, et élimine au maximum le Latency. Dans ma config DJ, le son sort du système de mixage en analogique pour être encodé via le Line-In sur l’ordinateur d’encodage/streaming pour envoyer sur le serveur. Ceci cause une demande de re-compression du son analogique en numérique, donc un temps de traitement, et un encodage pour l’envoie au serveur. Même si le Latency est minime, je peux avoir un 30~60 secondes de décalage, comparé au 15 seconde de mon Transcodeur.
Et j’oubliais, chaque client peut consommer de la mémoire vive, de 1 à 5Mo.
Mais bon, c’est mon côté perfectionniste qui parle, alors je crois que tu as l’ensemble des informations pour tes besoins.
J’ai aucun Raspberry Pi pour du serveur publique, alors mes recherches pour mes projets de ce genre sont pour du processeur X86, linux ou Windows. Mais pour le côté « DJ », j’ai tout sous Windows, et rien sur Linux car je n’utilise jamais Linux comme OS de travail, uniquement en serveur et/ou headless. Les Raspberry Pi pour moi ce sont de mini système linux en Headless, très peut de mes projets sont pour un usage de bureau, mis à part mon Deskboard, qui m’affiche l’heure, la température, combien de email en attentes, écouter ma radio, etc… Je trouve les RPi trop peut puissance pour faire du « bureau ».
Salut LevelKro,
Toujours intéressantes tes infos techniques ! Merci
Oui, je reste sur l’idée d’un seul système radio.
Pour le genre de musiques que je souhaite streamer (musiques médiévales) ayant des hauteurs sonores différentes et parfois mêmes des silences, est-ce que le CBR est conseillé ? N’y a-t’il pas un risque de « souffle » à ce moment-là ? Dans l’idéal, je ne souhaite pas modifier le son et le diffuser tel quel en qualité CD.
J’ai quelques questions :
quel player audio à afficher sur mon site conseilles-tu ?
quel encodeur (ou transcodeur, je ne sais pas la différence: y en a-t’il une d’ailleurs ?) pour les fichiers de musiques ?
est-ce que ton site est hébergé sur ton propre serveur ? C’est conseillé ou pas par rapport à un hébergement externe ?
quelle carte son externe (compatible linux) tu conseilles ?
Client… tu parles des logiciels ou des auditeurs ?
Ryzen 16 coeurs avec 32GB de ram
La vache, la bête !! Je fais pâle figure avec mon 4 coeurs 8GB de ram …
Peux importe la musique, le CBR est le « standard », le VBR est comme pour aider a réduire la taille.
Le « hic » avec le VBR c’est les applications. Pour que tu comprenne mieux voici un exemple.
Tu as une piste de 3 minutes, ce qui donnerais 3 Mo à 128kbps (environ). Alors ton app va diviser la taille par 128kbps et aura la duré total de la piste.
Avec un VBR, tu as une limite de 128kbps par exemple, ton fichier pèsera disons … 2.5Mo pour 3 minutes. L’app peux « questionner » le fichier pour obtenire le Bitrate, au lieu de donner 128kbps, il va donner la moyenne, disons 96kbps. Alors l’app va diviser 2.5Mo en 96kbps pour obtenir la duré. Mais le problème, c’est que les pointe à 128kbps et les absence à 0kbps seront pas calculé exactement, alors l’app peux couper la musique a 2m 50s ou à 3m 10s par exemple, estimant que la fin du fichier est cette valeur.
En rendant le CBR, tu assure que peux importe l’application, tu auras toujours la fin à la bonne place. Car même si tu as un silence, ce silence sera 128kbps … vide, mais la place est « réservé ».
Ou dans d’autres mots… ta piste est une bibliothèque, en CBR chaque livre a le même nombre de page, la même dimension (et chaque livre est un segment). En VBR, tu auras des livre avec aucune pages, d’autres avec plein de pages, la taille des livres est donc différente, et il est donc difficile de déterminer la place total de lecture.
Le seul moment ou un silence aura un impact est si tu défini une valeur de silence pour que ton serveur kick la source, ou que le transcodeur mix avec la prochaine piste. Habituellement c’est un valeur de 5s pour le transcodeur et 30s pour le serveur. Mais c’est une option que tu peux demander de ne pas gérer.
Avec le HTML5, tu n’as plus besoin de lecteur, la balise
Un Encodeur est l’application de convertion des fichiers, il en as plusieurs, des gratuits et payants, moi je roule avec du vieux stock comme App qui marche encore. J’édite avec Cool Edit Pro 2 (1996) et j’encode avec FFMpeg et un script python, quand j’ai besoin. Mais fait un bout j’ai pas eu a les utiliser.
Un Transcodeur est un programme qui va encoder les fichiers pour l’envoyer sur un serveur qui Stream, ou en d’autres mots c’est comme utiliser un lecteur Playlist qui envoie sur le serveur. Seulement, ce transcodeur, dans notre contexte, est automatisé, donc aucune interface, et va répéter la playlist en boucle (si tu as le mode aléatoire, ou Shuffle, c’est pratique pour varier).
J’ai eu plusieurs config, sur dédié, en VPS, depuis la maisons (voila très longtemps) avec ou sans mon site. Aujourd’hui avec les serveurs, l’usage est quand même assez léger pour faire plusieurs tâches.
J’ai actuellement 2 serveurs dédiés. J’ai donc l’un pour mes sites Web uniquement, et l’autre pour tout le reste; radio, minecraft, nextcloud, download center. J,ai aucun problème.
Quand j’était sur un VPS, j’avais beaucoup de warning vu que le CPU est partagé, mon Transcodeur utilisait 1cpu à 75%, le serveur utilisait 5%. Mais vu que le CPU n’était pas dédié, des actions des autres impactait la charge, et le fournisseur regardait qui en utilise le plus et me contactait inévitablement pour me demander de justifier l’usage.
Mais c’est que en VPS, faut éviter les économique, qui sont souvent mal géré, mal configuré et sur exploité.
Quand j’avais un seul dédié, tout était dessus et j’avais aucun impact notable. Imagine ce que j’ai dit plus au mais centralisé sur 1 seul serveur. Et je n’ai que 2 coeurs Intel Atom et 4GB Ram sur les serveurs.
J’ai déjà utilisé le tout sur un VPS de 256Mo Ram avec 1 vCPU et 20Go de disque pendant 5 ans au moins avant que je le passe sur un dédié. L’hébergeur était de qualité et j’ai jamais été inquiété sur l’usage. Le CPU était en dessous de 50% (moyenne de 0.25).
Tu n’as besoin d’aucune carte de son. Le tout est purement numérique. Le seul moment que tu en auras besoin est si tu as besoin d’une entré pour un Live par exemple, ou si tu as la possibilité de « monitoré » le stream en écoute. Bref, mes serveurs radio n’ont jamais eu de carte de son, et me serais impossible de l’ajouter même si j’en ferais la demande. J’utilie la carte de mon PC quand je stream live.
Toujours l’auditeur, qui est le client. Toi tu es la source, et le serveur de streaming … ben le serveur.
https://levelkro.com ← Site perso, je suis à le redessiner, le design n’est pas à la hauteur de mon talent (j’ai plus de 300 sites de créé a vie, j’étais programmeur Web avant)
Tu touches bien en programmation, du coup je comprends pas trop quand tu écris que tu es au chômage avec le niveau que tu as. ça me sidère.
j’ai parcouru tes sites. Je suis une bille perso…
Je galère à installer idjc un logiciel pour webradio, c’est dire. Mais j’avance petit à petit.
J’ai pu écouter le stream sur ton site.
Je ne suis pas au chômage actuellement. Mais je ne travail pas en informatique, je suis dans l’expédition.
Le problème est que j’ai aucun diplôme, une seul compagnie a vu mon potentiel et mon mis après un pied dans le département TI. J’ai donné de très bon résultat, mais la compagnie a été racheté et j’ai été « kick out » à cause de mon fiable niveau en anglais (parlé et écoute) et vu que j’avais un pied dans le centre de distribution (qui a fermé).
Une Web radio est ce qu’il y a de plus simple.
Tu as le serveur, tu pointe la « source » sur lui pour qui diffuse, le stream de sortie est récupérable via un lien (souvent http) et il est donc compatible avec 99% des lecteurs moderne.
Pour l’afficher sur un site, suffit de prendre ce lien et de l’inclure dans un tag <audio>, c’est encore plus simple aujourd’hui, avant fallait un applet Flash ou Java, sinon faut télécharger un fichier « Playlist »’ comme M3U, PLS, ASF, … par le client pour qui puisse l’ouvrir localement sur son ordinateur.
Après, ce lecteur de base va te fournir des options, que tu n’as qu’a ajuster à tes besoins.
IDJC est une application avec un GUI de mon premier regard sur le site. Il te faut alors impérativement un bureau. L’app seul va handicapé un peu les performances. Si il est « aussi bien fait » que Mixxx, sur un RPi c’est l’enfer et très lent. J’ai voulu que tester sur un Intel Atom 1.6GHz, 4GB Ram et les mp3 saccadait, alors sur un RPi en ARM avec 512Mo/1Gb, je vois mal l’utiliser.
Bon, une recherche avec mes termes sur Google donne peut de résultat d’application pour juste streamer sur le serveur depuis une playlist. Je ne sais pas si il y a moyen d’émuler un X86 sous ARM pour des apps linux. Si c’est le cas, tu pourrais tenter avec mon transcoder.
Mais cet articles utilise FFMpeg, ce que je pensais faires si je serais à ta place, il n’explique pas spécifiquement pour une playlist, de mon survol rapide, mais va surement t’aligner sur la bonne route si tu opte pour FFMpeg.
Si tu veux pousser la chose plus loin… un application Android pour ta radio ? (je ne sais pas si tu avais vu)
Salut LevelKro,
Bon, je n’ai pas tout saisi,notamment je n’ai pas compris ceci :
IDJC est une application avec un GUI de mon premier regard sur le site. Il te faut alors impérativement un bureau.
Toute ma problématique actuelle est de trouver un logiciel qui me permette de diffuser sans être derrière mon pc. Après que ce soit avec Icecast, Shoutcast, je t’avoue que les deux ayant de bonnes notes ce n’est pas important comme choix à faire pour moi. FFmpeg je ne sais pas vraiment ce que c’est…
Non vraiment ma problématique c’est l’automation et sur Linux y a pas grand chose. IJDC est apparemment très bien mais c’est la plaie pour l’installer. Je rame.
Pour le lecteur audio, j’ai mis en ligne mon site (je te mets le lien en MP) et j’avais déjà prévu le simple lecteur HTML5. Il est simple et compatible avec tous les navigateurs, c’est ce que je demande.
Un GUI, concrètement qu’est-ce que c’est ?
Oui, au départ j’ai pensé à une application Android…mais ça apporte quoi ?
GUI = Graphic User Interface
Il a besoin du bureau, comme une application Windows.
Ce que tu cherche est
CLI = Command Line Interface
Une interface en ligne de commande, qui peut s’exécuter en SSH ou via la console du RPi (si avec bureau) ou dans le « command prompt » de la version Lite. C’est comme une application DOS sous Windows (pour l’exemple).
FFMpeg est le programme de conversion et de traitement de fichiers vidéo et audio, il est complet et je l’utilise avec YT Downloader et mon projet de caméra de sécurité (avec le défunt FFServer).
Si tu fais ffmpeg --help, tu auras l’ensemble des commandes possible, et oui il en as beaucoup. ChatGPT pourrais t’aider en temps réel.
Ce sont des application qui me semble axé sur le GUI, pour Azuracast, il te faudrait installer Docker (que je n’ai jamais utilisé). Liquisoap semble dans la même famille.
Suivant mon idée avec FFMpeg, je suis tombé sur ça; IceS - XiphWiki
Soit ce que je te parlais, il est en plus de la famille Icecast …
Depuis la version 2.x, il peut pousser en OGG, ce que tu cherchais. Sinon il te fournisse une liste de « client source » a essayer; 3rd Party Applications — Icecast
ET discussion avec CHatGPT au sujet de FFMpeg, ce n’est pas compliqué…
Moi
Quel serais la ligne commande pour utiliser FFMpeg pour envoyer la lecture d’une playlist vers un serveur Icecast en localhost ?
ChatGPT
Voici la commande pour utiliser FFMpeg pour envoyer la lecture d’une playlist vers un serveur Icecast en localhost : ffmpeg -re -i playlist.m3u -f ogg icecast://localhost:8000/mountpoint
Assurez-vous de remplacer « playlist.m3u » par le chemin de votre playlist et « mountpoint » par le point de montage de votre flux sur Icecast.
Justement, à propos de point de montage, figure-toi que j’ai finalement installé Azuracast et qu’il répond à toutes mes attentes sauf que je n’entends rien pour l’instant quand je me rends sur mon site et que je lance la lecture audio.
La dernière difficulté (en date parce qu’il y en aura d’autres j’imagine) pour moi c’est justement ce fameux point de montage et tout ce qui en découle en paramétrages dont tu parles. Comme toi, l’anglais n’est pas ma langue et toutes les infos sont disponibles que dans cette langue.
J’ai interrogé ChatGPT sur la configuration d’AzuraCast mais elle ne m’a guère avancé dans ses réponses formatées.
Salut a tous!
Nouveau dans ce forum mais utilisateur d’un PI4 depuis 2 ans (1 avec Home assistant et 1 pour un Ambilight TV).
Maintenant j’aimerai aller plus loin et faire d’autre projet
A +
et puis je préfére une autonomie complète, c’est pour ça que je n’ai pas choisi de services comme radioking et autres par exemple.
SAMBroadcaster non plus mais y a un équivalent linux 
