Bonjour à tous,
J'ai, pour un client, un devis à étudier pour la réalisation et la mise en
place d'une webradio. Je précise que c'est une tout petite webradio, du
moins dans un premier temps (ce n'est pas oui-fm ou rtl2 , quoi..) et que
les besoins en bande passante ne m'ont pas l'air, à la louche et à premiere
vue, énorme. Cependant, cela reste de la webradio, et je dois avouer mes
limites en terme d'évaluation des besoins.
Je m'adresse donc à vous, professionnels de l'hébergement, qui ont
nécessairement eu affaire à ce genre de besoin, pour m'aider dans mon
évaluation.
Je précise que je suis à fond pour le libre, et que je ne m'orienterais pas
vers un serveur sous windows.
Je pensais dans un premier temps à un serveur dédié, type pentium 4 avec 1Go
de RAM (j'imagine qu'un stream nécessite de la ram) et une BP de l'ordre de
10Mo. (à priori, ça devrait suffire, du moins dans un premier temps. Je
m'attend a des pics d'une vingtaine, voire une trentaines d'écoutes
simultanées. En même temps, encore une fois, je n'ai vraiment pas d'idée
précise de ce que 10, 20, 50 écoutes simultanées représentent en terme de
BP. Est-ce que je peux partir sur un calcul théorique genre BP = nb
d'auditeur * BP moyenne d'un stream, et même là, qu'est-ce qu'on peut
imaginer comme BP moyenne d'un stream ? 50Ko ?
D'autre part. Si le traffic s'avère devenir rapidement plus élevé, il me
semble que c'est quelque chose, la webradio, qui s'accomode très bien d'un
load balancing.? Dans cette optique, et selon les estimations précises qui
me viendront par la suite, est-ce que je ne devrais pas privilégier une
solution a base de 2 serveurs avec 6Mo ou 10Mo de BP, chez des hebergeurs
bien-mais-pas-trop-chers, type CTN1, plutot qu'un gros serveur avec 20Mo de
BP garantie chez un hébergeur très-bien-mais-plus-cher.
Voilà un ptit peu mes interrogations sur le moment. Merci de me renseigner.
Pascal
Pour ce qui est de la config serveur, je pense du coup me tourner vers une solution type serveur à 50? HT / mois , puisque tu as l'air de dire qu'une machine "moyenne" suffirais. (genre un Athlon 2400XP avec 1Go de RAM, quoi, voire même moins que ça)
Attention, si tu dois faire du resample/réencodage à la volée, tu peux quand même avoir besoin de ressources de calcul.
Sinon, les besoins en puissance de calcul est quesi nul si tu n'a pas besoin de réencoder.
Pour ce qui est de la config serveur, je pense du coup me tourner vers une
solution type serveur à 50? HT / mois , puisque tu as l'air de dire qu'une
machine "moyenne" suffirais. (genre un Athlon 2400XP avec 1Go de RAM, quoi,
voire même moins que ça)
Attention, si tu dois faire du resample/réencodage à la volée, tu peux
quand même avoir besoin de ressources de calcul.
Sinon, les besoins en puissance de calcul est quesi nul si tu n'a pas
besoin de réencoder.
Pour ce qui est de la config serveur, je pense du coup me tourner vers une solution type serveur à 50? HT / mois , puisque tu as l'air de dire qu'une machine "moyenne" suffirais. (genre un Athlon 2400XP avec 1Go de RAM, quoi, voire même moins que ça)
Attention, si tu dois faire du resample/réencodage à la volée, tu peux quand même avoir besoin de ressources de calcul.
Sinon, les besoins en puissance de calcul est quesi nul si tu n'a pas besoin de réencoder.
Attention, si tu dois faire du resample/réencodage à la volée, tu peux quand même avoir besoin de ressources de calcul.
Oui, je m'en doute, mais je découvre la chose au fur et a mesure ou je développe avec vous ce post, et je me rend compte qu'effectivement la solution la plus simple / plus économique / plus réaliste serait de faire en sorte que le client place lui même ses flux/émissions sur le serveur. Je pourrais lui développer une interface web pour gérer les émissions (ie la playlist) en **collant** ses fichiers à des plages horaires déterminées. Le but n'étant en aucun cas de faire du direct.
Sinon, les besoins en puissance de calcul est quesi nul si tu n'a pas besoin de réencoder.
Bon à savoir, ça. Reste qu'une autre piste, pour combler l'éventuel écueil de portabilité persistant à bosser avec du ogg serait de prendre en entrée un flux mp3, (fichiers mp3 placés sur le serveur par le client), et d'en faire des fichiers ogg **au moment où** le fichier mp3 arriverait sur le serveur (ça peut être en tache de fond). Du coup, pas de réencodage en temps réel, mais qd même du réencodage une fois pour toute. (avec les DD disponibles aujourd'hui, je pense pouvoir stocker des flux en double (voire en n versions, si j'encode en différente qualité.) sans trop me poser de problème de place.
Tout de même, la RAM me semble importante, j'ai tord ?? j'imagine que gérer 100 flux simultanément, même si c'est pas très gourmand en CPU, ça prend un peu de mémoire.
Attention, si tu dois faire du resample/réencodage à la volée, tu peux
quand même avoir besoin de ressources de calcul.
Oui, je m'en doute, mais je découvre la chose au fur et a mesure ou je
développe avec vous ce post, et je me rend compte qu'effectivement la
solution la plus simple / plus économique / plus réaliste serait de faire
en sorte que le client place lui même ses flux/émissions sur le serveur. Je
pourrais lui développer une interface web pour gérer les émissions (ie la
playlist) en **collant** ses fichiers à des plages horaires déterminées.
Le but n'étant en aucun cas de faire du direct.
Sinon, les besoins en puissance de calcul est quesi nul si tu n'a pas
besoin de réencoder.
Bon à savoir, ça. Reste qu'une autre piste, pour combler l'éventuel écueil
de portabilité persistant à bosser avec du ogg serait de prendre en entrée
un flux mp3, (fichiers mp3 placés sur le serveur par le client), et d'en
faire des fichiers ogg **au moment où** le fichier mp3 arriverait sur le
serveur (ça peut être en tache de fond). Du coup, pas de réencodage en
temps réel, mais qd même du réencodage une fois pour toute. (avec les DD
disponibles aujourd'hui, je pense pouvoir stocker des flux en double (voire
en n versions, si j'encode en différente qualité.) sans trop me poser de
problème de place.
Tout de même, la RAM me semble importante, j'ai tord ?? j'imagine que gérer
100 flux simultanément, même si c'est pas très gourmand en CPU, ça prend un
peu de mémoire.
Attention, si tu dois faire du resample/réencodage à la volée, tu peux quand même avoir besoin de ressources de calcul.
Oui, je m'en doute, mais je découvre la chose au fur et a mesure ou je développe avec vous ce post, et je me rend compte qu'effectivement la solution la plus simple / plus économique / plus réaliste serait de faire en sorte que le client place lui même ses flux/émissions sur le serveur. Je pourrais lui développer une interface web pour gérer les émissions (ie la playlist) en **collant** ses fichiers à des plages horaires déterminées. Le but n'étant en aucun cas de faire du direct.
Sinon, les besoins en puissance de calcul est quesi nul si tu n'a pas besoin de réencoder.
Bon à savoir, ça. Reste qu'une autre piste, pour combler l'éventuel écueil de portabilité persistant à bosser avec du ogg serait de prendre en entrée un flux mp3, (fichiers mp3 placés sur le serveur par le client), et d'en faire des fichiers ogg **au moment où** le fichier mp3 arriverait sur le serveur (ça peut être en tache de fond). Du coup, pas de réencodage en temps réel, mais qd même du réencodage une fois pour toute. (avec les DD disponibles aujourd'hui, je pense pouvoir stocker des flux en double (voire en n versions, si j'encode en différente qualité.) sans trop me poser de problème de place.
Tout de même, la RAM me semble importante, j'ai tord ?? j'imagine que gérer 100 flux simultanément, même si c'est pas très gourmand en CPU, ça prend un peu de mémoire.
Lascap
http://www.icecast.org/3rdparty.php
Tx pour le lien. Intéressant de voir que winamp 3.x n'est pas supporté, alors que le 2.x l'est. Je note qu'effectivement, les clients sur MAC, par ex, ne sont pas pléthore, et que de plus ils n'ont pas l'air de particulièrement supporter ogg. Comme j'imagine que, à moins d'une bidouille innomable à base d'active X pour certains, javascript pour d'autres ou autre machin pas très crédible, je n'arriverais pas à savoir si l'internaute est capable de lire du ogg. Du coup, je suis bloqué : soit je propose 2 alternatives, ce que je vais sans doute faire, soit je propose uniquement du mp3 auquel cas je ne vais pas franchement dans le sens de la promotion du libre. .. pas glop
http://www.icecast.org/3rdparty.php
Tx pour le lien. Intéressant de voir que winamp 3.x n'est pas supporté,
alors que le 2.x l'est.
Je note qu'effectivement, les clients sur MAC, par ex, ne sont pas pléthore,
et que de plus ils n'ont pas l'air de particulièrement supporter ogg.
Comme j'imagine que, à moins d'une bidouille innomable à base d'active X
pour certains, javascript pour d'autres ou autre machin pas très crédible,
je n'arriverais pas à savoir si l'internaute est capable de lire du ogg. Du
coup, je suis bloqué : soit je propose 2 alternatives, ce que je vais sans
doute faire, soit je propose uniquement du mp3 auquel cas je ne vais pas
franchement dans le sens de la promotion du libre. .. pas glop
Tx pour le lien. Intéressant de voir que winamp 3.x n'est pas supporté, alors que le 2.x l'est. Je note qu'effectivement, les clients sur MAC, par ex, ne sont pas pléthore, et que de plus ils n'ont pas l'air de particulièrement supporter ogg. Comme j'imagine que, à moins d'une bidouille innomable à base d'active X pour certains, javascript pour d'autres ou autre machin pas très crédible, je n'arriverais pas à savoir si l'internaute est capable de lire du ogg. Du coup, je suis bloqué : soit je propose 2 alternatives, ce que je vais sans doute faire, soit je propose uniquement du mp3 auquel cas je ne vais pas franchement dans le sens de la promotion du libre. .. pas glop
Lascap
Calimero wrote:
Je pense que sous Mac tu peux aussi générer du MP3. En tout cas, il faut s'assurer de l'ensemble de la chaine...
Et pour répondre à cette interrogation, à priori je vais bosser avec un partenaire sur ce coup là, ingénieur du son de son état. Je dois proposer une solution clef en main, machines de prod incluses. La chaine est donc maitrisée, ou du moins le sera. reste à trouver les meilleurs choix techniques.
Calimero wrote:
Je pense que sous Mac tu peux aussi générer du MP3. En tout cas, il faut
s'assurer de l'ensemble de la chaine...
Et pour répondre à cette interrogation, à priori je vais bosser avec un
partenaire sur ce coup là, ingénieur du son de son état. Je dois proposer
une solution clef en main, machines de prod incluses. La chaine est donc
maitrisée, ou du moins le sera. reste à trouver les meilleurs choix
techniques.
Je pense que sous Mac tu peux aussi générer du MP3. En tout cas, il faut s'assurer de l'ensemble de la chaine...
Et pour répondre à cette interrogation, à priori je vais bosser avec un partenaire sur ce coup là, ingénieur du son de son état. Je dois proposer une solution clef en main, machines de prod incluses. La chaine est donc maitrisée, ou du moins le sera. reste à trouver les meilleurs choix techniques.
GuiZmo34
Attention, si tu dois faire du resample/réencodage à la volée, tu peux quand même avoir besoin de ressources de calcul.
Oui, je m'en doute, mais je découvre la chose au fur et a mesure ou je développe avec vous ce post, et je me rend compte qu'effectivement la solution la plus simple / plus économique / plus réaliste serait de faire en sorte que le client place lui même ses flux/émissions sur le serveur. Je pourrais lui développer une interface web pour gérer les émissions (ie la playlist) en **collant** ses fichiers à des plages horaires déterminées. Le but n'étant en aucun cas de faire du direct.
Sinon, les besoins en puissance de calcul est quesi nul si tu n'a pas besoin de réencoder.
Bon à savoir, ça. Reste qu'une autre piste, pour combler l'éventuel écueil de portabilité persistant à bosser avec du ogg serait de prendre en entrée un flux mp3, (fichiers mp3 placés sur le serveur par le client), et d'en faire des fichiers ogg **au moment où** le fichier mp3 arriverait sur le serveur (ça peut être en tache de fond). Du coup, pas de réencodage en temps réel, mais qd même du réencodage une fois pour toute. (avec les DD disponibles aujourd'hui, je pense pouvoir stocker des flux en double (voire en n versions, si j'encode en différente qualité.) sans trop me poser de problème de place.
Tout de même, la RAM me semble importante, j'ai tord ?? j'imagine que gérer 100 flux simultanément, même si c'est pas très gourmand en CPU, ça prend un peu de mémoire.
Bonsoir,
Tu devrais faire deux flux:
- shoutcast > mp3 (proprio)
- icecast > ogg (libre
Cordialement, GuiZmo34
Attention, si tu dois faire du resample/réencodage à la volée, tu peux
quand même avoir besoin de ressources de calcul.
Oui, je m'en doute, mais je découvre la chose au fur et a mesure ou je
développe avec vous ce post, et je me rend compte qu'effectivement la
solution la plus simple / plus économique / plus réaliste serait de faire
en sorte que le client place lui même ses flux/émissions sur le serveur. Je
pourrais lui développer une interface web pour gérer les émissions (ie la
playlist) en **collant** ses fichiers à des plages horaires déterminées.
Le but n'étant en aucun cas de faire du direct.
Sinon, les besoins en puissance de calcul est quesi nul si tu n'a pas
besoin de réencoder.
Bon à savoir, ça. Reste qu'une autre piste, pour combler l'éventuel écueil
de portabilité persistant à bosser avec du ogg serait de prendre en entrée
un flux mp3, (fichiers mp3 placés sur le serveur par le client), et d'en
faire des fichiers ogg **au moment où** le fichier mp3 arriverait sur le
serveur (ça peut être en tache de fond). Du coup, pas de réencodage en
temps réel, mais qd même du réencodage une fois pour toute. (avec les DD
disponibles aujourd'hui, je pense pouvoir stocker des flux en double (voire
en n versions, si j'encode en différente qualité.) sans trop me poser de
problème de place.
Tout de même, la RAM me semble importante, j'ai tord ?? j'imagine que gérer
100 flux simultanément, même si c'est pas très gourmand en CPU, ça prend un
peu de mémoire.
Attention, si tu dois faire du resample/réencodage à la volée, tu peux quand même avoir besoin de ressources de calcul.
Oui, je m'en doute, mais je découvre la chose au fur et a mesure ou je développe avec vous ce post, et je me rend compte qu'effectivement la solution la plus simple / plus économique / plus réaliste serait de faire en sorte que le client place lui même ses flux/émissions sur le serveur. Je pourrais lui développer une interface web pour gérer les émissions (ie la playlist) en **collant** ses fichiers à des plages horaires déterminées. Le but n'étant en aucun cas de faire du direct.
Sinon, les besoins en puissance de calcul est quesi nul si tu n'a pas besoin de réencoder.
Bon à savoir, ça. Reste qu'une autre piste, pour combler l'éventuel écueil de portabilité persistant à bosser avec du ogg serait de prendre en entrée un flux mp3, (fichiers mp3 placés sur le serveur par le client), et d'en faire des fichiers ogg **au moment où** le fichier mp3 arriverait sur le serveur (ça peut être en tache de fond). Du coup, pas de réencodage en temps réel, mais qd même du réencodage une fois pour toute. (avec les DD disponibles aujourd'hui, je pense pouvoir stocker des flux en double (voire en n versions, si j'encode en différente qualité.) sans trop me poser de problème de place.
Tout de même, la RAM me semble importante, j'ai tord ?? j'imagine que gérer 100 flux simultanément, même si c'est pas très gourmand en CPU, ça prend un peu de mémoire.
Bonsoir,
Tu devrais faire deux flux:
- shoutcast > mp3 (proprio)
- icecast > ogg (libre
Cordialement, GuiZmo34
Calimero
Lascap wrote:
Tx pour le lien. Intéressant de voir que winamp 3.x n'est pas supporté, alors que le 2.x l'est.
Moui, enfin ca ca vient à mon avis du fait que winamp 3 est une merde et que même Nullsoft en avait conscience. ;-)
La compatiblité d'icecast avec winamp vient de shoutcast (le serveur de stream de nullsoft, gratuit mais fermé).
Depuis la version 2.2, si mes souvenirs de changelog sont bons, icecast accepte le protocole client de shoutcast.
Pour Winamp2 et 5 (vu que la version 3 n'intéresse personne), il y a le plugin oddcast qui peut feeder vers du shoutcast ou du icecast en mp3 et en ogg.
D'autre part, les serveurs peuvent diffuser du contenu local.
Je note qu'effectivement, les clients sur MAC, par ex, ne sont pas pléthore, et que de plus ils n'ont pas l'air de particulièrement supporter ogg. Comme j'imagine que, à moins d'une bidouille innomable à base d'active X pour certains, javascript pour d'autres ou autre machin pas très crédible, je n'arriverais pas à savoir si l'internaute est capable de lire du ogg. Du coup, je suis bloqué : soit je propose 2 alternatives, ce que je vais sans doute faire, soit je propose uniquement du mp3 auquel cas je ne vais pas franchement dans le sens de la promotion du libre. .. pas glop
Faut parfois être pragmatique: avec du MP3 tu auras très peu de soucis. Le ogg imposera à certains de tes clients d'ajouter un plugin dans leur player, ce qui peut en bloquer certains. L'intégrisme technique doit parfois s'effacer face à la vraie vie. ;-)
-- @+ Calimero
Lascap wrote:
Tx pour le lien. Intéressant de voir que winamp 3.x n'est pas supporté,
alors que le 2.x l'est.
Moui, enfin ca ca vient à mon avis du fait que winamp 3 est une merde et
que même Nullsoft en avait conscience. ;-)
La compatiblité d'icecast avec winamp vient de shoutcast (le serveur de
stream de nullsoft, gratuit mais fermé).
Depuis la version 2.2, si mes souvenirs de changelog sont bons, icecast
accepte le protocole client de shoutcast.
Pour Winamp2 et 5 (vu que la version 3 n'intéresse personne), il y a le
plugin oddcast qui peut feeder vers du shoutcast ou du icecast en mp3 et
en ogg.
D'autre part, les serveurs peuvent diffuser du contenu local.
Je note qu'effectivement, les clients sur MAC, par ex, ne sont pas pléthore,
et que de plus ils n'ont pas l'air de particulièrement supporter ogg.
Comme j'imagine que, à moins d'une bidouille innomable à base d'active X
pour certains, javascript pour d'autres ou autre machin pas très crédible,
je n'arriverais pas à savoir si l'internaute est capable de lire du ogg. Du
coup, je suis bloqué : soit je propose 2 alternatives, ce que je vais sans
doute faire, soit je propose uniquement du mp3 auquel cas je ne vais pas
franchement dans le sens de la promotion du libre. .. pas glop
Faut parfois être pragmatique: avec du MP3 tu auras très peu de soucis.
Le ogg imposera à certains de tes clients d'ajouter un plugin dans leur
player, ce qui peut en bloquer certains. L'intégrisme technique doit
parfois s'effacer face à la vraie vie. ;-)
Tx pour le lien. Intéressant de voir que winamp 3.x n'est pas supporté, alors que le 2.x l'est.
Moui, enfin ca ca vient à mon avis du fait que winamp 3 est une merde et que même Nullsoft en avait conscience. ;-)
La compatiblité d'icecast avec winamp vient de shoutcast (le serveur de stream de nullsoft, gratuit mais fermé).
Depuis la version 2.2, si mes souvenirs de changelog sont bons, icecast accepte le protocole client de shoutcast.
Pour Winamp2 et 5 (vu que la version 3 n'intéresse personne), il y a le plugin oddcast qui peut feeder vers du shoutcast ou du icecast en mp3 et en ogg.
D'autre part, les serveurs peuvent diffuser du contenu local.
Je note qu'effectivement, les clients sur MAC, par ex, ne sont pas pléthore, et que de plus ils n'ont pas l'air de particulièrement supporter ogg. Comme j'imagine que, à moins d'une bidouille innomable à base d'active X pour certains, javascript pour d'autres ou autre machin pas très crédible, je n'arriverais pas à savoir si l'internaute est capable de lire du ogg. Du coup, je suis bloqué : soit je propose 2 alternatives, ce que je vais sans doute faire, soit je propose uniquement du mp3 auquel cas je ne vais pas franchement dans le sens de la promotion du libre. .. pas glop
Faut parfois être pragmatique: avec du MP3 tu auras très peu de soucis. Le ogg imposera à certains de tes clients d'ajouter un plugin dans leur player, ce qui peut en bloquer certains. L'intégrisme technique doit parfois s'effacer face à la vraie vie. ;-)
-- @+ Calimero
R12y
On Sun, 09 Oct 2005 23:47:59 +0200, Lascap wrote:
(avec les DD disponibles aujourd'hui, je pense pouvoir stocker des flux en double (voire en n versions, si j'encode en différente qualité.) sans trop me poser de problème de place.
Les DD coutent cher sur un dédié. Pour la bonne raison que si tu as besoin de grands disques, c'est que tu va faire télécharger. Or la denrée rare (plus ou moins indirectement) c'est le débit....
Tout de même, la RAM me semble importante, j'ai tord ?? j'imagine que gérer 100 flux simultanément, même si c'est pas très gourmand en CPU, ça prend un peu de mémoire.
Sasn encodage à la volée, sur un LAN (100Mbps) u'utilise Icecast pour aussi bien de la video et de l'audio, sur une machine à 256Mo sans problème. Il ne swappe pas tant que ça, donc j'en déduis qu'il n'est pas vraiment à court de mémoire. Par contre je n'ai pas 100 streams, juste une dizaine, pour tests.
(avec les DD
disponibles aujourd'hui, je pense pouvoir stocker des flux en double (voire
en n versions, si j'encode en différente qualité.) sans trop me poser de
problème de place.
Les DD coutent cher sur un dédié. Pour la bonne raison que si tu as besoin
de grands disques, c'est que tu va faire télécharger. Or la denrée rare
(plus ou moins indirectement) c'est le débit....
Tout de même, la RAM me semble importante, j'ai tord ??
j'imagine que
gérer 100 flux simultanément, même si c'est pas très gourmand en CPU, ça
prend un peu de mémoire.
Sasn encodage à la volée, sur un LAN (100Mbps) u'utilise Icecast pour
aussi bien de la video et de l'audio, sur une machine à 256Mo sans
problème. Il ne swappe pas tant que ça, donc j'en déduis qu'il n'est pas
vraiment à court de mémoire. Par contre je n'ai pas 100 streams, juste une
dizaine, pour tests.
(avec les DD disponibles aujourd'hui, je pense pouvoir stocker des flux en double (voire en n versions, si j'encode en différente qualité.) sans trop me poser de problème de place.
Les DD coutent cher sur un dédié. Pour la bonne raison que si tu as besoin de grands disques, c'est que tu va faire télécharger. Or la denrée rare (plus ou moins indirectement) c'est le débit....
Tout de même, la RAM me semble importante, j'ai tord ?? j'imagine que gérer 100 flux simultanément, même si c'est pas très gourmand en CPU, ça prend un peu de mémoire.
Sasn encodage à la volée, sur un LAN (100Mbps) u'utilise Icecast pour aussi bien de la video et de l'audio, sur une machine à 256Mo sans problème. Il ne swappe pas tant que ça, donc j'en déduis qu'il n'est pas vraiment à court de mémoire. Par contre je n'ai pas 100 streams, juste une dizaine, pour tests.
La compatiblité d'icecast avec winamp vient de shoutcast (le serveur de stream de nullsoft, gratuit mais fermé).
Depuis la version 2.2, si mes souvenirs de changelog sont bons, icecast accepte le protocole client de shoutcast.
je suis pas sur de comprendre. ça sous entend que pour diffuser sur winamp, il faut utiliser le protocole shoutcast qui serait d'une certaine manière intégré à icecast, c'est ça ?? Genre une routine qui permettrait à icecast de diffuser vers du winamp, en utilisant des libs shoutcast ??
Faut parfois être pragmatique: avec du MP3 tu auras très peu de soucis. Le ogg imposera à certains de tes clients d'ajouter un plugin dans leur player, ce qui peut en bloquer certains. L'intégrisme technique doit parfois s'effacer face à la vraie vie. ;-)
Oui, tu as sans doute (et malheureusement :(:(:() raison. il y a de grandes chances pour que je m'oriente vers ça, du moins par défaut. mais je compte bien proposer ogg qd même, pour les plus avertis. (après tout, dans la mesure où les gens peuvent avoir une meilleure qualité de stream pour le même débit, ça serait dommage de les en priver !)
La compatiblité d'icecast avec winamp vient de shoutcast (le serveur de
stream de nullsoft, gratuit mais fermé).
Depuis la version 2.2, si mes souvenirs de changelog sont bons, icecast
accepte le protocole client de shoutcast.
je suis pas sur de comprendre. ça sous entend que pour diffuser sur winamp,
il faut utiliser le protocole shoutcast qui serait d'une certaine manière
intégré à icecast, c'est ça ?? Genre une routine qui permettrait à icecast
de diffuser vers du winamp, en utilisant des libs shoutcast ??
Faut parfois être pragmatique: avec du MP3 tu auras très peu de soucis.
Le ogg imposera à certains de tes clients d'ajouter un plugin dans leur
player, ce qui peut en bloquer certains. L'intégrisme technique doit
parfois s'effacer face à la vraie vie. ;-)
Oui, tu as sans doute (et malheureusement :(:(:() raison. il y a de grandes
chances pour que je m'oriente vers ça, du moins par défaut. mais je compte
bien proposer ogg qd même, pour les plus avertis. (après tout, dans la
mesure où les gens peuvent avoir une meilleure qualité de stream pour le
même débit, ça serait dommage de les en priver !)
La compatiblité d'icecast avec winamp vient de shoutcast (le serveur de stream de nullsoft, gratuit mais fermé).
Depuis la version 2.2, si mes souvenirs de changelog sont bons, icecast accepte le protocole client de shoutcast.
je suis pas sur de comprendre. ça sous entend que pour diffuser sur winamp, il faut utiliser le protocole shoutcast qui serait d'une certaine manière intégré à icecast, c'est ça ?? Genre une routine qui permettrait à icecast de diffuser vers du winamp, en utilisant des libs shoutcast ??
Faut parfois être pragmatique: avec du MP3 tu auras très peu de soucis. Le ogg imposera à certains de tes clients d'ajouter un plugin dans leur player, ce qui peut en bloquer certains. L'intégrisme technique doit parfois s'effacer face à la vraie vie. ;-)
Oui, tu as sans doute (et malheureusement :(:(:() raison. il y a de grandes chances pour que je m'oriente vers ça, du moins par défaut. mais je compte bien proposer ogg qd même, pour les plus avertis. (après tout, dans la mesure où les gens peuvent avoir une meilleure qualité de stream pour le même débit, ça serait dommage de les en priver !)
Lascap
R12y wrote:
Sinon tu as aussi ceci, chez OVH: http://www.ovh.com/fr/produits/streaming_relay.xml
Oui, ça peut être intéressant. Toutefois, je suis assez curieux, et j'aime autant, autant que possible, développer et maitriser plutot que de fournir des solutions déjà toutes faites.
R12y wrote:
Sinon tu as aussi ceci, chez OVH:
http://www.ovh.com/fr/produits/streaming_relay.xml
Oui, ça peut être intéressant. Toutefois, je suis assez curieux, et j'aime
autant, autant que possible, développer et maitriser plutot que de fournir
des solutions déjà toutes faites.
Sinon tu as aussi ceci, chez OVH: http://www.ovh.com/fr/produits/streaming_relay.xml
Oui, ça peut être intéressant. Toutefois, je suis assez curieux, et j'aime autant, autant que possible, développer et maitriser plutot que de fournir des solutions déjà toutes faites.
