problème de débit de sortie

Bonjour,

j'ai un pb idiot que je n'arrive pas à comprendre.

j'héberge chez moi un serveur helix version 8. Je délivre essentiellement des fichiers audio, encodés avec l'encodeur helix, en trois débits différents : 56k 128k et 256k, bien sûr en surestream.

Etant chez wanadoo, je n'ai qu'un débit de 128k en upstream.

Le problème que j'ai est le suivant : lorsque je me connecte à l'extérieur sur mon serveur, helix ne détecte pas la partie à 128k, et me délivre mes fichiers directement en 256k, provoquant un rebuffering toutes les 30 secondes à peu près.

Quelqu'un peut me dire la cause du pb???

Merci
Serge

 

question 1- Pourquoi integrer un flux de 256 Kbps si ta connection en upload n'est que de 128 K ?
ensuite, la premiere vitesse demandée est celle qui est inscrite dans les prefs du lecteur, a savoir peut etre 512 Kbps si a l'exterieur tu es connecté en ADSL. C'est donc normal qu'il essaie de proposer la plus haut vitesse en premier lieu. Modifies les prefs du client, ca devrait changer.

 

Bonjour,

réponse 1 : parce que l'upload va forcément augmenter (wanadoo est en retard sur les concurrents, qui sont de pls en plus en 256k en upload) et que vaux mieux prévoir maintenant que me repalucher tous les réencodage de ma musique. Deuxième raison, j'écoute aussi ma musique sur mon réseau local à la maison.

Sur la deuxième réponse, je veux bien croire, mais d'abord ce n'est pas ce qui est dit dans la doc real serveur sur surestream, et deuxio ça m'est arrivé, lorsqu'on était plusieurs à écouter de la musique sur mon serveur, à descendre à 30kb/sec au niveau du client.

Ma seule conclusion pour l'instant, mais j'aimerais avoir confirmation, c'est que real serveur n'a aucun moyen de tester le débit entre le player et le serveur (ce qui est peut-être normal avec le protocole RTSP) et que surestram ajuste le débit uniquement ben fonction du nombre de players connectés en même temps.

Merci pour ta réponse!
Serge

 

il y a effectivement un dialogue client-serveur pour déterminer si il y a une perte de paquets. si il y a une perte, le débit inférieur est envoyé. Si le débit recu dépasse le débit envoyé, il passe au début supérieur.
Mais sur une ligne de type ADSL, des choses variables en solidité peuvent arriver...
Pour ce qui est de plusieurs clients en meme temps sur cette connexion, c'est normal qu'il divise la bande passante par le nombre de client. Pour éviter ca, faut brider manuellement le nombre max de client sur le serveur.

 

Merci. Alors, je ne comprends pas l'origine du problème. S'il y a un dialogue entre le client et le serveur, pourquoi ce dialogue ne détecte pas ce petit bout de ligne à 128k entre mon routeur et le DSLAM ???

Ce que je voulais dire, c'est que le seul cas où ça marche, c'est quand effectivment il y aplusieurs connexions simultanées. Mais c'est rare (j'ai en moyenne 1800 connexions par mois sur ce site, c'est perso pas pro).

Si tu as le courage, c'est sur http://www.soudoplatoff.net:8081/cd il faut cliquer sur "ceux qu'on peut écouter". Mais c'est vraiment à l'occasion.

Merci de ta réponse.
Serge

 

j'ai cliqué... rien ne s'affiche.
Je re tenterais plus tard...
Es-tu sur du contenu de ton fichier en surestream 128K dans le meme fichier ?

 

Si tu as un firewall, il faut ouvrir le port 8081 pour que ça marche, sinon c'est le vide.

J'ai une procédure automatique d'encodage de mes fichiers, j'utilise la commande batch de real encoder, et c'est un fichier batch généré automatiquement par une procédure de Microsoft access, donc a priori les fichiers sont bien encodés à trois niveaux.

Je l'ai vérifié, car ce que dit bien la doc c'est que encoder en 256k délivre en fait du 180, 128k du 95 et en 56k du 40k, et ça m'est arrivé d'avoir du 95 ou du 40k

Merci

 

Par curioité, ton encoder helix il encode sur demande d'un client? a la connexion de celui ci? ou il encode en boucle et diffuse ?

Je recherche le moyen d'encoder a la demande du client....le flux encodé etant capté par un server de diffusion et donc diffusé par ce dernier...

 

Mon encodeur encode à ma demande à moi!!! Mais mon serveur sert à la demande du client.

Il y a deux logiciels : l'encodeur, et le serveur.

L'encodeur transforme un fichier son en entrée en un fichier .rm de type real média. Je fais ça off line, après une première phase de transformation de mon CD en fichiers .wav J'utilise audiograbber pour ça (qui est gratuit), mais il y a plein d'autres outils de ripping, et ce sont ces fichiers .wav qui sont en entrée de mon encodeur.

Le fichier .rm généré est mis dans un répertoire, et j'indique à mon serveur helix où se trouve la racine de ce répertoire. Ensuite c'est une logique de serveur : dès qu'un client fait une demande (en rtsp sur le port 554) alors le serveur hélix délivre le streaming.

Je ne vois pas bien l'intérêt d'encoder à la demande, car une fois que c'est fait, tu n'as plus à le faire...

En revanche, si tu parles de flux encodé, alors le serveur hélix possède un mode de streaming "live", par exemple si tu veux streamer la sortie d'une webcam. Il faut paramétrer ça dans le serveur lui-même.

Ai-je répondu à la question?
Merci
Serge

 

OUI parfaitement clair mais ca ne resoud donc pas mon probleme (t'inquiete, tu n'y es pour rien ).

Effectivement, je cherche a piloter mon encodage(mon encoder donc) par le server de flux. Une connexion d'un client lance l'encodage d'un fichier dont le flux est capté par le server, qui diffuse au client.

Pourquoi?

J'ai plein de sources (trop maybe) en format non streamable, et pas la place de concerver mes fichiers dans les deux formats.