Discussion :

[Slaya]

Bonjour,

Je m'intéresse au développement d'une web radio un peu spéciale où chaque auditeur recevrait un streaming différent selon les préférences musicales qu'il a choisi.
Au niveau applicatif je n'ai encore rien fait, mais il se pose déjà le problème de l'architecture réseau. Tous les fichiers audio seront sur un serveur et le logiciel élaborera une playlist différente pour chaque client qui se connecte. Et là je me prends la tête pour essayer de diminuer au maximum l'utilisation de la bande passante du serveur car financièrement ça revient très cher pour un service proposé gratuitement.
J'ai fais des recherches et je suis tombé sur le p2p streaming, très intéressant mais dans mon cas, c'est totalement inutile n'est-ce pas?
Je cherche d'autres technologies de ce genre qui peuvent faire économiser de la bande passante ou capable de faire du "load balancing".
Si vous avez entendu parler de ce genre de choses et qui peuvent convenir à mon cas, merci de m'en informer, et de faire avancer le projet.

Merci d'avance.
@+

[ludovic.fernandez]

Salut,
Pour réduire au maximum l'utilisation de la BP, je pense qu'il faurait éviter les connexions par l'emploi de RTP.

[vic]

A priori tu est obligé de servir 1 flux par client donc pas moyen de faire appel à des serveurs de streaming spécialisés. De plus il faut tenir compte des logiciels existants comme winamp, s'il faut télécharger un logiciel spécial pour écouter la radio ca risque de faire fuir les auditeurs.

Donc pas beaucoup de solutions pour limiter la BP, tu peux jouer sur l'encodage et le bitrate, par ex en ogg/vorbis tu peux atteindre un bitrate plus bas par rapport au mp3 pour la même qualité.

Effectivement je crois que le RTP gâche un peu de BP mais winamp & co utilisent le TCP (HTTP-like).

[Yabo]

Je suis entrain de réaliser une application du même type que toi Un serveur qui devra gérer pleins de straming audios différents. Pour l'instant j'ai seulement défini mon choix sur le protocole UDP en réimplémentant mes propres mécanismes de sécurité pour gagner un peu en BP de côté là. Sinon il y a une RFC qui définit un protocole de streaming audio/vidéo. J'ai plus le numéro de la RFC sous la main mais dés que je le retrouve je te le donnerai

[vic]

(au passage si c'est juste pour générer des flux à la carte ça existe déjà, mais j'ai codé un truc similaire il y a peu ca doit être la mode)

[ludovic.fernandez]

Effectivement je crois que le RTP gâche un peu de BP mais winamp & co utilisent le TCP (HTTP-like).

Je voulais dire l'inverse.

Et effectivement, la RFC dont tu parles doit être RTP over UDP, non ?!?

[Slaya]

Salut,

De plus il faut tenir compte des logiciels existants comme winamp, s'il faut télécharger un logiciel spécial pour écouter la radio ca risque de faire fuir les auditeurs.

Justement, à part le steaming Shoutcast qui est supporté par quasiment tous les players actuels sur les plateformes les utilisées (WMP, Real, Winamp, iTunes, XMMS,...), je ne vois pas d'autre solution qui permettrait de satisfaire un maximum de monde sans télécharger et installer quoique ce soit. C'est pour cela que je réfléchis à un moyen d'empaqueter un player dans un applet java si c'est possible et ainsi garder une compatibilité maximale et éviter de faire installer quoique ce soit aux auditeurs.

Donc pas beaucoup de solutions pour limiter la BP, tu peux jouer sur l'encodage et le bitrate, par ex en ogg/vorbis tu peux atteindre un bitrate plus bas par rapport au mp3 pour la même qualité.

Effectivement, j'ai pensé à ça, je retiens le ogg, et je cherche en même temps d'autres codecs, le meilleur étant d'avoir quelquechose de lossless. Puisque le player sera fait maison, je me suis dit qu'un codec même "sorti des bas fonds" peut faire l'affaire, puisqu'on controle l'encodage et le décodage de bout en bout, peut-etre que je me trompe...

Yabo>>> Ok, merci, j'attends le n°

au passage si c'est juste pour générer des flux à la carte ça existe déjà, mais j'ai codé un truc similaire il y a peu ca doit être la mode

J'imagine bien que ça existe déjà, mais n'en saurais-tu pas plus sur leur focntionnement technique? est-ce que c'est genre des grosses boîtes qui prennent une baie de serveurs et des Gbps de bande passante? ou y-a-t-il un moyen d'être plus malin que ça? Et si t'as codé un truc similaire, fais nous partager ton expérience, comment tu t'y es pris, quel langage, etc. (à moins que ça soit top secret ).

Je voulais dire l'inverse.

Donc finalement, RTP c'est beaucoup plus meilleur, si j'ai bien tout suivi.
Je vais me documenter à ce sujet, grand merci.

@+

[ludovic.fernandez]

En fait RTP est over UDP. Il n'y a donc ni connexion blocante, ni de mécanisme inutile pour le multimédia d'assurance de transport de données (Voir aussi la FEC et la compression d'entête).

[vic]

Slaya : J'ai fait ca en perl en utilisant le proto shoutcast (c'est du http avec quelques headers en plus). Mais je ne suis pas soucié de l'usage de la BP, et je ne pense pas que ca soit possible en unicast. Au maximum tu peux jouer sur la taille des headers, ce qui doit faire 20 octets sur un mtu de 1500 ...

Personnellement je pense que le TCP est nécéssaire car en UDP il faudra imaginer un système de correction d'erreurs (audio oblige) qui consommera
de la BP de toutes façons.

[ludovic.fernandez]

faudra imaginer un système de correction d'erreurs (audio oblige) qui consommera
de la BP de toutes façons.

Justement non et j'ai expliqué pourquoi .

[vic]

Euh ... soit j'ai mal compris, soit on n'est pas d'accord Tu parles de FEC, or comme tu le dis toi même "la FEC repond au probleme de perte de paquets en joignant a chacun d'entre eux une copie des precedents."

Donc je soutiens qu'on utilise plus de BP
On ne peut pas se permettre de perdre des paquets sans quoi le son sera de mauvaise qualité.

[ludovic.fernandez]

Je crois que nous ne sommes pas d'accord et l'explication se trouve certainement sur le net. Le raisonnement n'est pas aussi simple mais une étude menée à l'INRIA démontre justement un rapport entre BP/fenêtrage TCP/Vitesse d'envoi des paquets et taille des paquets audio.

Ludovic