[Interopcast-general] Des nouvelles

[Pierre Jarillon]

Bonjour à tous,
Malgré le silence assourdissant de ces dernières semaines, le projet avance !
http://savannah.nongnu.org/projects/interopcast/

Icecast a été décortiqué par les 8 étudiants, le code a été commenté, 
restructuré et nettoyé. Le code original ne comportait pratiquement aucun
commentaire. Il y avait aussi du code mort.
Le code modifié est disponible sur 
http://savannah.nongnu.org/cgi-bin/viewcvs/interopcast/ENSEIRB/icecast/

Les étudiants se sont partagé le travail. Un groupe travaille maintenant sur 
l'administration à distance ou locale du serveur, un autre se penche plus 
particulièrement sur la sécurité, un autre sur la documentation...

Voici un courrier très intéressant d'Arnaud Ebalard que je tiens à faire 
partager avec tous ceux que le sujet intéresse.

================================================
Bonsoir,

petit mail d'infos en vrac sur ICECAST.

J'ai mis à jour le CVS avec un nouveau module de gestion des formats 
(modification précédente du CVS mercredi). Maintenant, un plugin unique se 
charge de gérer tous les types de formats Ogg !

Je m'explique : un flux Ogg possède un type mime "application/ogg" ( 
http://www.xiph.org/archives/speex-dev/200302/0009.html ). Peu importe quel 
type de format il encapsule. La reconnaissance du format doit donc être gérée 
au niveau du plugin et non par le type mime. C'est ce que fait maintenant le 
plugin ogg.


Comment ça marche ?

C'est pas compliqué : ICECAST reçoit un flux de type mime "application/ogg" 
(dans le parser). Le module de format fournit alors le plugin ogg. Celui-ci 
reçoit ensuite les données brutes de la stream et se charge à partir de la 
première page (58 octets) de déterminer le type de format encapsulé par 
l'ogg. Une fois ceci fait, les pointeurs de fonctions vers les fonctions de 
traitement ogg générales sont mis à jour avec les fonctions adaptées au 
format trouvé (si celui-ci est géré par ICECAST, cela va de soi !). Tout est 
transparent pour l'utilisateur du module de format qui ne se rend compte de 
rien. 

Et je prends les devants en répondant à la question que se pose sûrement Seb : 
mais le plugin général, s'il a récupéré les premières données brutes, elles 
sont perdues pour le plugin spécifique qui prend sa suite ?

Eh non. En effet, le plugin général ogg reçoit un volume de données brute 
toujours bien supérieur au volume de données nécessaire (les 58 premiers 
octets de la première page qui contient le premier paquet) mais ça n'est pas 
grave car le plugin ogg générique conserve les données brutes passées et 
lorsqu'il fait la bascule sur le plugin spécifique, il réalise un reset du 
buffer de synchro ogg et y remet ensuite les données conservées pour qu'elles 
soient disponible au plugin spécifique. Ainsi, au prochain appel de la 
fonction de traitement des données, ce sera celle de traitement spécifique 
qui sera utilisée : elle mettra les données qui lui sont passées dans le 
buffer de synchro à la suite des précédentes. Elle réalisera ensuite une 
demande de sortie de page du buffer et récupérera comme par magie la première 
page de la stream !

J'ajoute de plus que la récupération du premier paquet de la stream peut se 
faire en plusieurs fois (c'est peu probable mais c'est géré!).

Ceci ouvre ainsi ICECAST à d'autres format que le vorbis. J'ai notamment lu la 
doc de speex pour réaliser un plugin ogg speex. Son écriture est calquée sur 
le contenu du plugin spécifique vorbis. Le speex utilise pour les metadonnées 
le même shéma que le vorbis : il est donc possible d'utiliser directement les 
fonctions vorbis_synthesis_headerin et autres pour récupérer les métadonnées 
du second paquet de la stream. Bémol : je ne l'ai pas fait (l'extraction des 
métadonnées) pour le moment, pour une raison simple qui est que je n'ai pas 
trouvé de streamer speex et qu'il n'est défini à aucun endroit le contenu des 
différents champs de métadonnées (Artist ? title ? ...).

Pour résoudre le pb, j'ai pris contact avec Jean-Marc Valin (créateur de 
speex) pour avoir des infos techniques et voir s'il avait connaissance de 
l'existence de streamers speex. Du point de vue technique, il m'a dépanné 
mais pour ce qui est des streamers, il n'est pas plus avancé que moi. Il 
existe des encodeurs et des décodeurs mais pas de streamers capable de gérer 
un envoi régulier de données encodées en speex. En effet, lorsque speex est 
utilisé dans le cadre de VoIP il n'est pas encapsulé dans de l'ogg pour des 
raisons de gains de place, il est transmis directement encapsulés en RTP, 
donc on a quelques logiciels de communication VoIP speex mais pas de streamer 
ogg speex. J'en reste là pour ce pb.

J'ai aussi lu la doc de fLaC (cf xiph.org) qui a l'air d'être un format pas 
mal par ses possibilités. Comme pour speex, il n'y a pas besoin a priori de 
librairie spécifique à rajouter à ICECAST, les métadonnées se trouvant là 
encore au niveau du second paquet dans un format compatible vorbis. Le plugin 
doit là encore se calquer sur ceux de vorbis et de speex.

Maintenant, je passe à un autre pb : quelqu'un connait-il quelqu'un sur terre 
qui utilise ICECAST pour relayer du mp3. En gros, si qqn trouve un streamer 
mp3 compatible ICECAST (version 2), j'achète! Après des essais avec shout, 
shoutcast, liveice, liveice plugin pour xmms, darkice, et d'autres, je 
renonce.
================================================

Après avoir étudié mp3 et ogg-vorbis, Arnaud est arrivé à la conclusion que
mp3 en mode stream était un gentil bricolage, mais que le stream ogg lui
paraissait techniquement très supérieur.

La documentation sera générée delon la DTD Docbook.

QUESTION :
Existe-t'il des documents normatifs, genre RFC pour définir les streams et
les métadonnées qu'ils contiennent ?

Je crois qu'il serait bon que chacun commence à charger le projet, à le 
compiler et à le tester.

-- 
Pierre Jarillon - http://pjarillon.free.fr/
Vice-président de l'ABUL : http://abul.org/