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
Voilà un ptit peu mes interrogations sur le moment. Merci de me renseigner. Pascal
Dominique ROUSSEAU
Le dim, 09 oct 2005 at 10:48 GMT, Pascal Menut a écrit : [...]
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,
Ce qui compte c'est l'utilisation en pic, si la BP est plafonnée. Et le mode de calcul que tu indiques est le bon :)
et même là, qu'est-ce qu'on peut imaginer comme BP moyenne d'un stream ? 50Ko ?
Pour de la BP, on parle généralement en kilobits par seconde (kbps), plutot qu'en ko/s. Pour un flux musical, tu auras une qualité très correcte à partir de 128 kbps (en mp3) voire 96 (en ogg/vorbis). Pour du "parlé", tu peux réduire ça d'au moins 1 tiers. Donc tu peux faire passer de 8 à 10 flux simultanés dans 1Mbps. Pour 20 à 30 flux, on arrive donc à 3 ou 4 Mbps.
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.?
Tu peux effectivement répliquer le flux sur plusieurs serveurs qui le serviront ensuite aux clients. Toutefois, il vaut mieux limiter le nombre détapes, qui ajoutent un délai par rapport au "live" à chaque fois, du fait des différents tampons mis en place pour limiter l'impact d'une congestion temporaire du réseau.
Dom
Le dim, 09 oct 2005 at 10:48 GMT, Pascal Menut <pascal@_NOSPAM_petitegraine.com> a écrit :
[...]
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,
Ce qui compte c'est l'utilisation en pic, si la BP est plafonnée.
Et le mode de calcul que tu indiques est le bon :)
et même là, qu'est-ce qu'on peut imaginer comme BP moyenne d'un stream
? 50Ko ?
Pour de la BP, on parle généralement en kilobits par seconde (kbps),
plutot qu'en ko/s.
Pour un flux musical, tu auras une qualité très correcte à partir de 128
kbps (en mp3) voire 96 (en ogg/vorbis). Pour du "parlé", tu peux réduire
ça d'au moins 1 tiers.
Donc tu peux faire passer de 8 à 10 flux simultanés dans 1Mbps.
Pour 20 à 30 flux, on arrive donc à 3 ou 4 Mbps.
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.?
Tu peux effectivement répliquer le flux sur plusieurs serveurs qui le
serviront ensuite aux clients. Toutefois, il vaut mieux limiter le
nombre détapes, qui ajoutent un délai par rapport au "live" à chaque
fois, du fait des différents tampons mis en place pour limiter l'impact
d'une congestion temporaire du réseau.
Le dim, 09 oct 2005 at 10:48 GMT, Pascal Menut a écrit : [...]
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,
Ce qui compte c'est l'utilisation en pic, si la BP est plafonnée. Et le mode de calcul que tu indiques est le bon :)
et même là, qu'est-ce qu'on peut imaginer comme BP moyenne d'un stream ? 50Ko ?
Pour de la BP, on parle généralement en kilobits par seconde (kbps), plutot qu'en ko/s. Pour un flux musical, tu auras une qualité très correcte à partir de 128 kbps (en mp3) voire 96 (en ogg/vorbis). Pour du "parlé", tu peux réduire ça d'au moins 1 tiers. Donc tu peux faire passer de 8 à 10 flux simultanés dans 1Mbps. Pour 20 à 30 flux, on arrive donc à 3 ou 4 Mbps.
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.?
Tu peux effectivement répliquer le flux sur plusieurs serveurs qui le serviront ensuite aux clients. Toutefois, il vaut mieux limiter le nombre détapes, qui ajoutent un délai par rapport au "live" à chaque fois, du fait des différents tampons mis en place pour limiter l'impact d'une congestion temporaire du réseau.
Tu n'as pas forcément besoin d'une machine de folie, niveau ram/proc, vu que le serveur de diffusion (genre icecast) ne fait aucun encodage. C'est le "disk jockey" (par exemple un plugin sous Winamp, type oddcast) qui encode et streame vers le(s) serveur(s) de diffusion qui ensuite diffuse(nt).
Pour la bande passante, si tu streames de la musique en MP3 et que tu veux de la bonne qualité tu peux faire du 128kbit/s stereo 44khz. Tu peux éventuellement descendre à 96kbit/s avec encore une qualité acceptable. Après tu as toutes sortes de réglages... sur l'échantillonage, mono/stéréo, bitrate... Faut tester, voir ce que ton client juge acceptable.
Après, le calcul est effectivement N auditeur * débit stream. Attention à ne pas mélanger Mo/s et Mbits/s ! Y a un facteur 8 entre les deux...
Admettons que tu aies 100 users simultanés à 64kbit/s, il faudra donc en gros 6.5Mbit/s... disons 7mbit/s.
Tu peux effectivement répartir la charge sur différents serveurs (icecast par exemple génère une playlist à la volée contenant les différents serveurs). Un serveur peut servir de réplicateur (il se connecte à un serveur maître et réplique le flux). Tout dépend bien sûr de ton serveur de diffusion. Tu peux du coup avoir 2 ou 3 serveurs chez différents prestataires pour réduire l'impact de la perte d'un serveur. Penser dans ce cas à la charge additionnelle en terme d'infogérance. A terme, de toute façon, si la radio marche très bien l'évolution passera par des serveurs de diffusion multiples.
Ensuite, le choix de l'hébergeur... on en revient toujours au même point: quelle importance ton client accorde-t-il au service ? Est-ce un bonus limite "passe-temps" ? est-ce un service critique ? Besoin d'un accompagnement en terme d'infogérance ? Une garantie de niveau de service avec pénalités ?
Chez les discounter, tu as OVH avec sa formule Stream 40. C'est un petit Celeron 2Ghz / 128Mo, 40Mbit/s. Sinon les CTN1, OVH, Ikexpress proposent tous des serveurs à 10Mbit/s 512Mo ou 1Go de RAM pour une 50e HT/mois.
Après, en fonction du matériel/services/garanties, les prix vont bien évidemment monter.
D'autre part, ne pas négliger la part soft de l'ensemble. Icecast par exemplepermet de faire pas mal de choses et nécessite quand même quelques temps pour bien tester/comprendre les settings. C'est du temps qui coute. Si on vise d'autres formats de stream (type Real), les licences vont sans doute assez sérieusement alourdir le budget.
Tu n'as pas forcément besoin d'une machine de folie, niveau ram/proc, vu
que le serveur de diffusion (genre icecast) ne fait aucun encodage.
C'est le "disk jockey" (par exemple un plugin sous Winamp, type oddcast)
qui encode et streame vers le(s) serveur(s) de diffusion qui ensuite
diffuse(nt).
Pour la bande passante, si tu streames de la musique en MP3 et que tu
veux de la bonne qualité tu peux faire du 128kbit/s stereo 44khz. Tu
peux éventuellement descendre à 96kbit/s avec encore une qualité acceptable.
Après tu as toutes sortes de réglages... sur l'échantillonage,
mono/stéréo, bitrate... Faut tester, voir ce que ton client juge acceptable.
Après, le calcul est effectivement N auditeur * débit stream.
Attention à ne pas mélanger Mo/s et Mbits/s ! Y a un facteur 8 entre les
deux...
Admettons que tu aies 100 users simultanés à 64kbit/s, il faudra donc en
gros 6.5Mbit/s... disons 7mbit/s.
Tu peux effectivement répartir la charge sur différents serveurs
(icecast par exemple génère une playlist à la volée contenant les
différents serveurs). Un serveur peut servir de réplicateur (il se
connecte à un serveur maître et réplique le flux). Tout dépend bien sûr
de ton serveur de diffusion.
Tu peux du coup avoir 2 ou 3 serveurs chez différents prestataires pour
réduire l'impact de la perte d'un serveur. Penser dans ce cas à la
charge additionnelle en terme d'infogérance.
A terme, de toute façon, si la radio marche très bien l'évolution
passera par des serveurs de diffusion multiples.
Ensuite, le choix de l'hébergeur... on en revient toujours au même
point: quelle importance ton client accorde-t-il au service ? Est-ce un
bonus limite "passe-temps" ? est-ce un service critique ?
Besoin d'un accompagnement en terme d'infogérance ? Une garantie de
niveau de service avec pénalités ?
Chez les discounter, tu as OVH avec sa formule Stream 40. C'est un petit
Celeron 2Ghz / 128Mo, 40Mbit/s.
Sinon les CTN1, OVH, Ikexpress proposent tous des serveurs à 10Mbit/s
512Mo ou 1Go de RAM pour une 50e HT/mois.
Après, en fonction du matériel/services/garanties, les prix vont bien
évidemment monter.
D'autre part, ne pas négliger la part soft de l'ensemble. Icecast par
exemplepermet de faire pas mal de choses et nécessite quand même
quelques temps pour bien tester/comprendre les settings. C'est du temps
qui coute.
Si on vise d'autres formats de stream (type Real), les licences vont
sans doute assez sérieusement alourdir le budget.
Tu n'as pas forcément besoin d'une machine de folie, niveau ram/proc, vu que le serveur de diffusion (genre icecast) ne fait aucun encodage. C'est le "disk jockey" (par exemple un plugin sous Winamp, type oddcast) qui encode et streame vers le(s) serveur(s) de diffusion qui ensuite diffuse(nt).
Pour la bande passante, si tu streames de la musique en MP3 et que tu veux de la bonne qualité tu peux faire du 128kbit/s stereo 44khz. Tu peux éventuellement descendre à 96kbit/s avec encore une qualité acceptable. Après tu as toutes sortes de réglages... sur l'échantillonage, mono/stéréo, bitrate... Faut tester, voir ce que ton client juge acceptable.
Après, le calcul est effectivement N auditeur * débit stream. Attention à ne pas mélanger Mo/s et Mbits/s ! Y a un facteur 8 entre les deux...
Admettons que tu aies 100 users simultanés à 64kbit/s, il faudra donc en gros 6.5Mbit/s... disons 7mbit/s.
Tu peux effectivement répartir la charge sur différents serveurs (icecast par exemple génère une playlist à la volée contenant les différents serveurs). Un serveur peut servir de réplicateur (il se connecte à un serveur maître et réplique le flux). Tout dépend bien sûr de ton serveur de diffusion. Tu peux du coup avoir 2 ou 3 serveurs chez différents prestataires pour réduire l'impact de la perte d'un serveur. Penser dans ce cas à la charge additionnelle en terme d'infogérance. A terme, de toute façon, si la radio marche très bien l'évolution passera par des serveurs de diffusion multiples.
Ensuite, le choix de l'hébergeur... on en revient toujours au même point: quelle importance ton client accorde-t-il au service ? Est-ce un bonus limite "passe-temps" ? est-ce un service critique ? Besoin d'un accompagnement en terme d'infogérance ? Une garantie de niveau de service avec pénalités ?
Chez les discounter, tu as OVH avec sa formule Stream 40. C'est un petit Celeron 2Ghz / 128Mo, 40Mbit/s. Sinon les CTN1, OVH, Ikexpress proposent tous des serveurs à 10Mbit/s 512Mo ou 1Go de RAM pour une 50e HT/mois.
Après, en fonction du matériel/services/garanties, les prix vont bien évidemment monter.
D'autre part, ne pas négliger la part soft de l'ensemble. Icecast par exemplepermet de faire pas mal de choses et nécessite quand même quelques temps pour bien tester/comprendre les settings. C'est du temps qui coute. Si on vise d'autres formats de stream (type Real), les licences vont sans doute assez sérieusement alourdir le budget.
-- @+ Calimero
Lascap
Merci pour toutes ces précisions !! Je vais donc checker du côté de Icecast, ça m'a l'air d'être une bonne solution. 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) Dernière question cependant : si je pars sur un seul serveur, avec une solution a base de Icecast, est-ce que je pourrais, sans trop de problèmes, ajouter un second serveur par la suite ? (par sans trop de problème, j'entend une config du second serveur pendant un temps donné, et surtout une coupure très limitée du service, voire pas de coupure : ie je passerais le temps qu'il faut pour configurer mon second serveur, lui mettre dans la tronche tous les streams, mais je n'aurais pas besoin outre mesure de modifier le premier)
Merci encore en tout cas Lascap
Merci pour toutes ces précisions !!
Je vais donc checker du côté de Icecast, ça m'a l'air d'être une bonne
solution.
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)
Dernière question cependant : si je pars sur un seul serveur, avec une
solution a base de Icecast, est-ce que je pourrais, sans trop de problèmes,
ajouter un second serveur par la suite ? (par sans trop de problème,
j'entend une config du second serveur pendant un temps donné, et surtout
une coupure très limitée du service, voire pas de coupure : ie je passerais
le temps qu'il faut pour configurer mon second serveur, lui mettre dans la
tronche tous les streams, mais je n'aurais pas besoin outre mesure de
modifier le premier)
Merci pour toutes ces précisions !! Je vais donc checker du côté de Icecast, ça m'a l'air d'être une bonne solution. 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) Dernière question cependant : si je pars sur un seul serveur, avec une solution a base de Icecast, est-ce que je pourrais, sans trop de problèmes, ajouter un second serveur par la suite ? (par sans trop de problème, j'entend une config du second serveur pendant un temps donné, et surtout une coupure très limitée du service, voire pas de coupure : ie je passerais le temps qu'il faut pour configurer mon second serveur, lui mettre dans la tronche tous les streams, mais je n'aurais pas besoin outre mesure de modifier le premier)
Merci encore en tout cas Lascap
Calimero
Lascap wrote:
Merci pour toutes ces précisions !! Je vais donc checker du côté de Icecast, ça m'a l'air d'être une bonne solution.
C'est ce qu'utilise par exemple frequence3.org (avec peut être des modifications, je ne sais pas), me semble.
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)
Oui ca doit suffire. Ne pas oublier toutefois que tu n'as aucune redondance matériel sur ces offres (en même temps, vu le prix, faut pas pousser). Une disque qui lache, t'as une machine à remonter avec l'interruption de service que ca implique.
Dernière question cependant : si je pars sur un seul serveur, avec une solution a base de Icecast, est-ce que je pourrais, sans trop de problèmes, ajouter un second serveur par la suite ? (par sans trop de problème, j'entend une config du second serveur pendant un temps donné, et surtout une coupure très limitée du service, voire pas de coupure : ie je passerais le temps qu'il faut pour configurer mon second serveur, lui mettre dans la tronche tous les streams, mais je n'aurais pas besoin outre mesure de modifier le premier)
J'ai seulement joué de manière superficielles avec icecast, mais normalement, tu communiques dans le fichier xml de conf la liste des serveurs utilisables. Cette liste est envoyée sous forme de playlist aux utilisateurs.
Avec un plugin de diffusion comme oddcast, tu peux envoyer ton flux audio en différentes qualités à différents serveurs. Il faut donc ajouter une nouvelle cible dans ton soft de diffusion pour alimenter le nouveau serveur. Alternativement, tu peux configurer le second (ou n-ième) serveur comme un esclave/relais du serveur principal. Ca introduit par contre une latence additionnelle (ce qui peut être +/- embêtant si on veut une certaine interactivité avec les auditeurs).
A priori, l'interruption de service est minime (le temps de recharger le fichier de conf, pour propager les nouveaux serveurs).
Ne pas oublier de budgetiser l'équipement côté "dj" (table de mixage ? connexion pour upload...) A noter qu'il est possible pour icecast (de mémoire) de diffuser du contenu alternatif en cas de perte du flux "dj".
En tout état de cause, icecast.org dispose de docs et de ML et de forums où tu auras des informations plus fiables et des retours d'expérience réelle.
-- @+ Calimero
Lascap wrote:
Merci pour toutes ces précisions !!
Je vais donc checker du côté de Icecast, ça m'a l'air d'être une bonne
solution.
C'est ce qu'utilise par exemple frequence3.org (avec peut être des
modifications, je ne sais pas), me semble.
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)
Oui ca doit suffire. Ne pas oublier toutefois que tu n'as aucune
redondance matériel sur ces offres (en même temps, vu le prix, faut pas
pousser). Une disque qui lache, t'as une machine à remonter avec
l'interruption de service que ca implique.
Dernière question cependant : si je pars sur un seul serveur, avec une
solution a base de Icecast, est-ce que je pourrais, sans trop de problèmes,
ajouter un second serveur par la suite ? (par sans trop de problème,
j'entend une config du second serveur pendant un temps donné, et surtout
une coupure très limitée du service, voire pas de coupure : ie je passerais
le temps qu'il faut pour configurer mon second serveur, lui mettre dans la
tronche tous les streams, mais je n'aurais pas besoin outre mesure de
modifier le premier)
J'ai seulement joué de manière superficielles avec icecast, mais
normalement, tu communiques dans le fichier xml de conf la liste des
serveurs utilisables. Cette liste est envoyée sous forme de playlist aux
utilisateurs.
Avec un plugin de diffusion comme oddcast, tu peux envoyer ton flux
audio en différentes qualités à différents serveurs. Il faut donc
ajouter une nouvelle cible dans ton soft de diffusion pour alimenter le
nouveau serveur.
Alternativement, tu peux configurer le second (ou n-ième) serveur comme
un esclave/relais du serveur principal. Ca introduit par contre une
latence additionnelle (ce qui peut être +/- embêtant si on veut une
certaine interactivité avec les auditeurs).
A priori, l'interruption de service est minime (le temps de recharger le
fichier de conf, pour propager les nouveaux serveurs).
Ne pas oublier de budgetiser l'équipement côté "dj" (table de mixage ?
connexion pour upload...)
A noter qu'il est possible pour icecast (de mémoire) de diffuser du
contenu alternatif en cas de perte du flux "dj".
En tout état de cause, icecast.org dispose de docs et de ML et de forums
où tu auras des informations plus fiables et des retours d'expérience
réelle.
Merci pour toutes ces précisions !! Je vais donc checker du côté de Icecast, ça m'a l'air d'être une bonne solution.
C'est ce qu'utilise par exemple frequence3.org (avec peut être des modifications, je ne sais pas), me semble.
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)
Oui ca doit suffire. Ne pas oublier toutefois que tu n'as aucune redondance matériel sur ces offres (en même temps, vu le prix, faut pas pousser). Une disque qui lache, t'as une machine à remonter avec l'interruption de service que ca implique.
Dernière question cependant : si je pars sur un seul serveur, avec une solution a base de Icecast, est-ce que je pourrais, sans trop de problèmes, ajouter un second serveur par la suite ? (par sans trop de problème, j'entend une config du second serveur pendant un temps donné, et surtout une coupure très limitée du service, voire pas de coupure : ie je passerais le temps qu'il faut pour configurer mon second serveur, lui mettre dans la tronche tous les streams, mais je n'aurais pas besoin outre mesure de modifier le premier)
J'ai seulement joué de manière superficielles avec icecast, mais normalement, tu communiques dans le fichier xml de conf la liste des serveurs utilisables. Cette liste est envoyée sous forme de playlist aux utilisateurs.
Avec un plugin de diffusion comme oddcast, tu peux envoyer ton flux audio en différentes qualités à différents serveurs. Il faut donc ajouter une nouvelle cible dans ton soft de diffusion pour alimenter le nouveau serveur. Alternativement, tu peux configurer le second (ou n-ième) serveur comme un esclave/relais du serveur principal. Ca introduit par contre une latence additionnelle (ce qui peut être +/- embêtant si on veut une certaine interactivité avec les auditeurs).
A priori, l'interruption de service est minime (le temps de recharger le fichier de conf, pour propager les nouveaux serveurs).
Ne pas oublier de budgetiser l'équipement côté "dj" (table de mixage ? connexion pour upload...) A noter qu'il est possible pour icecast (de mémoire) de diffuser du contenu alternatif en cas de perte du flux "dj".
En tout état de cause, icecast.org dispose de docs et de ML et de forums où tu auras des informations plus fiables et des retours d'expérience réelle.
-- @+ Calimero
Aurélien
"Calimero" a écrit dans le message de news:4349315c$0$642$
Lascap wrote:
Merci pour toutes ces précisions !! Je vais donc checker du côté de Icecast, ça m'a l'air d'être une bonne solution.
C'est ce qu'utilise par exemple frequence3.org (avec peut être des modifications, je ne sais pas), me semble.
Fréquence3 utilise quand meme majoritairement des serveurs Shoutcast.
Aurélien
"Calimero" <calimero.ng@evolutive.org> a écrit dans le message de
news:4349315c$0$642$626a14ce@news.free.fr...
Lascap wrote:
Merci pour toutes ces précisions !!
Je vais donc checker du côté de Icecast, ça m'a l'air d'être une bonne
solution.
C'est ce qu'utilise par exemple frequence3.org (avec peut être des
modifications, je ne sais pas), me semble.
Fréquence3 utilise quand meme majoritairement des serveurs Shoutcast.
"Calimero" a écrit dans le message de news:434935ba$0$12620$
Aurélien wrote:
Fréquence3 utilise quand meme majoritairement des serveurs Shoutcast.
Effectivement, je viens de regarder. Je sais plus pourquoi j'ai fait cette association icecast/F3...
Il me semble que leurs serveurs qui diffusent de l'ogg vorbis sont sous icecast.
Aurélien
Lascap
Et oggvorbis, c'est bien implémenté, sous MAC, ça, non??? (a priori les systèmes de "création des supports à diffuser" seront sous MAC) Et à choisir, je préfére bosser avec du ogg.
Et oggvorbis, c'est bien implémenté, sous MAC, ça, non??? (a priori les
systèmes de "création des supports à diffuser" seront sous MAC)
Et à choisir, je préfére bosser avec du ogg.
Et oggvorbis, c'est bien implémenté, sous MAC, ça, non??? (a priori les systèmes de "création des supports à diffuser" seront sous MAC) Et à choisir, je préfére bosser avec du ogg.
Calimero
Lascap wrote:
Et oggvorbis, c'est bien implémenté, sous MAC, ça, non??? (a priori les systèmes de "création des supports à diffuser" seront sous MAC) Et à choisir, je préfére bosser avec du ogg.
L'oggvorbis, bien que techniquement supérieur et libre, n'est pas ce qu'il y a de plus répandu. Donc méfiance au niveau des players capables d'écouter le stream.
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...
Tout soft ne peut pas streamer directement en sortie vers un serveur ice/shoutcast.
Comme clients source: http://www.icecast.org/3rdparty.php
-- @+ Calimero
Lascap wrote:
Et oggvorbis, c'est bien implémenté, sous MAC, ça, non??? (a priori les
systèmes de "création des supports à diffuser" seront sous MAC)
Et à choisir, je préfére bosser avec du ogg.
L'oggvorbis, bien que techniquement supérieur et libre, n'est pas ce
qu'il y a de plus répandu. Donc méfiance au niveau des players capables
d'écouter le stream.
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...
Tout soft ne peut pas streamer directement en sortie vers un serveur
ice/shoutcast.
Comme clients source:
http://www.icecast.org/3rdparty.php
Et oggvorbis, c'est bien implémenté, sous MAC, ça, non??? (a priori les systèmes de "création des supports à diffuser" seront sous MAC) Et à choisir, je préfére bosser avec du ogg.
L'oggvorbis, bien que techniquement supérieur et libre, n'est pas ce qu'il y a de plus répandu. Donc méfiance au niveau des players capables d'écouter le stream.
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...
Tout soft ne peut pas streamer directement en sortie vers un serveur ice/shoutcast.
Comme clients source: http://www.icecast.org/3rdparty.php
