Christian Schaller (qui est un des développeurs) a écrit un article de présentation assez complet et très accessible sur cette infrastructure réellement innovante.
À ce sujet une petite citation : GStreamer was not a simple re-implementation of something which had been done before. I guess we did what Steve Balmer claims free software never does: we innovated.
Le fait que le projet soit désormais hébergé sur Freedesktop.org est une indication qu'il est maintenant reconnu comme une application ayant vocation à être largement interopérable et standardisée. L'article aborde les questions suivantes :
- Présentation de base
- Gstreamer dans l'embarqué
- Gstreamer sur les serveurs
- Gstreamer sur les ordinateurs de bureau
- L'utilisation dans GNOME
- L'utilisation dans KDE
- Les plans pour le futur
- Les logiciels concurrents
Aller plus loin
- L'article sur OSNews (16 clics)
- Le site de Gstreamer (15 clics)
- Le pipeline editor (11 clics)
- Freedesktop.org (4 clics)
# Il faut bien que quelqu'un se dévoue pour la faire ...
Posté par pinceau . Évalué à -6.
[^] # Re: Il faut bien que quelqu'un se dévoue pour la faire ...
Posté par sirrus . Évalué à -8.
# quelqu'un se dévoue ?
Posté par mansuetus (site web personnel) . Évalué à 0.
et puis c'est un peu prétencieux son *we inovated*, non ? je pense pas que apache ou gnu, dans leur globalité n'aient fait que du copier/coller...
dans le concept de base (ils ont pas inventé le C) peut être (et encore, pas sur que tous les projets Open source ne le soient... ) mais dans la qualité de réalisation, dans la puissance du code, dans les performances...
bref, pas embalé par la dépèche, mais si quelqu'un se sent de me démontrer que j'ai tort, en m'expliquant clairement en quoi c'est mieux/innovant, je suis prenneur !
[^] # Re: quelqu'un se dévoue ?
Posté par Jerome Herman . Évalué à 7.
Par exemple on peut prendre un fichier vob DVD, le passer dans un demuxeur, passer le flux DVD dans un decodeur Video, puis dans un encodeur Xvid, pendant que les 5 channels audio seront splittes en deux faisceaux (gauche+cente, droite +centre) puis passe dans un encodeur vorbis. Au final les flux videos et audios seront recuperes par un derniers filtres et lies dans un OGG.
Voila poyur la difference, ca permet de construire un decodeur/encodeur/diffuseur brique a brique tranquilement.
Pour le cote innovation par contre il y a un hic, Direct Show fait ca depuis des annees, et il y a meme une interface graphique qui marche tres bein (Graphedit). Bon ca passe pas par le reseau mais ca revient un peu au meme....
Kha
[^] # Re: quelqu'un se dévoue ?
Posté par Black Fox . Évalué à 2.
Cette ressemblance avec DirectShow etait précisée dans l'article.
[^] # Re: quelqu'un se dévoue ?
Posté par Barnabé . Évalué à 3.
Je ne sais pas si Video-LAN fait ce genre de choses :
http://gstreamer.net/images/gst-editor-0.4.1-clean.png(...)
À mon humble avis, il fallait entendre « pipe » plutôt au sens composition d'outils, comme pour le shell, mais avec un joli cliquodrome, et c'est assez innovant pour ce que je connais des applications de streaming existantes.
[^] # Re: quelqu'un se dévoue ?
Posté par imr . Évalué à 6.
Facile.
Tu aurais lu l'article avant de commenter, tu aurais compris en quoi c'est mieux/innovant.
Voila, en quoi tu avais tort, et c'est expliqué clairement.
[^] # Re: quelqu'un se dévoue ?
Posté par mansuetus (site web personnel) . Évalué à 1.
[^] # Re: quelqu'un se dévoue ?
Posté par patrick_g (site web personnel) . Évalué à 0.
c'est pas ma dépèche qui est importante c'est l'article de présentation (que je trouve très bien fait).
[^] # Re: quelqu'un se dévoue ?
Posté par Christophe Fergeau . Évalué à 2.
Pour convertir un fichier flac en mp3, il suffit de faire un truc du genre
gst-launch filesrc location=fichier.flac ! flacdec ! lameenc ! filesink location=fichier.mp3
et voilà. Le fin du fin est que les dernières versions preservent meme les tags lors du passage flac->mp3 :)
Tu peux aussi facilement jouer le fichier en replacant lameenc ! filesink par ossink, en ajoutant les elements qui vont bien, tu peux ajouter un plugin de visualisation pendant que la musique joue, ou bien avec le demuxer approprie, tu dois pouvoir utiliser une piste audio d'un dvd en entree, ...
Bref, GStreamer est très prometteur (même si c'est malheureusement pas encore suffisamment stable à mon gout)
# Re: Où en est Gstreamer ?
Posté par Alan_T . Évalué à 1.
Pour le son ou la video, cela rame (meme sans utiliser tout le proc). Alors que Xine ou Xmms s'en débrouillent très bien ?
Est-ce de ma faute ou quelqu'un d'autre a remarqué ce genre de comportement ?
[^] # Re: Où en est Gstreamer ?
Posté par Christophe Fergeau . Évalué à 1.
Si tu veux dire que le son a tendance à sauter, c'est la faute du scheduler du noyau, ca marche nettement mieux en 2.6. Xine et xmms n'ont pas ce pb car ils creent plusieurs threads de lecture pour augmenter leurs chances qu'il y en ait un qui soit schedulé à temps...
[^] # Re: Où en est Gstreamer ?
Posté par seedeexeen . Évalué à 2.
Les applis qui merde au niveau son sont souvent des applis qui ne remplissent pas le buffer de la carte son. Si tu n'envoies que 30ms de données à la carte, faut pas se plaindre de ne pas être schedulé à temps pour envoyer la suite.
xine est multithreadé et il n'y a pas de pb de scheduling.
mplayer est monothreadé et il n'y pas de pb non plus.
vlc n'a pas de pb non plus.
gstreamer est foireux alors on accuse le noyau ?...
[^] # Re: Où en est Gstreamer ?
Posté par Christophe Fergeau . Évalué à 1.
Des coupures dans la musique qui peuvent aller jusqu'à 2/3 secondes avec un noyau 2.4 et qui disparaissent totalement avec un 2.6, c'est quand même indicateur d'un problème dans le scheduler, même si ce n'est pas nécessairement entièrement la faute du noyau.
gstreamer pourrait effectivement faire des efforts pour éviter ce genre de pbs mais
1) ca peut etre vu comme un hack pourri pour contourner un bug du noyau
2) c'est pas forcément facile à faire par rapport à des "simples" lecteurs de musique/vidéos qui n'ont que ce genre de détails à faire fonctionner correctement (la phrase précédente ne signifie pas que je trouve que c'est super facile de faire un player qui tue sa mère, j'essaie juste de mettre en relief le fait que gstreamer est beaucoup plus complexe architecturalement et dans ses objectifs que mplayer ou xine)
[^] # Re: Où en est Gstreamer ?
Posté par Alan_T . Évalué à 2.
Mais lorsque j'utilise gstreamer, cela saute, cela cafouille, et des fois cela plante... D'où cela vient-il ? La faute aux codecs ? Ou l'architecture est encore à revoir ?
Ce qui m'étonne le plus, c'est que dans l'article sur OSNews, je m'attendais à voir au moins un passage sur: "Bon, pour l'instant les perfs sont pas grandioses à cause de ..., on va améliorer ça dans l'avenir en faisant ...".
Mais là, RIEN ! Pas même la moindre remarque sur le fait que cela rame tout de même considérablement (et ne dis pas le contraire, je ne vois pas pourquoi le 2.4 aurait du mal à jouer du son ou afficher une vidéo tout ça à cause de problème de scheduling... la complexité du scheduler n'est rien devant la décompression vidéo ou audio).
Alors, je suis _un_peu_ étonné ! Voila !
[^] # Re: Où en est Gstreamer ?
Posté par Christophe Fergeau . Évalué à 1.
Si le noyau est pas très sympa avec, et la schedule au petit bonheur la chance, c'est à dire un coup regulièrement toutes les 100 ms, puis ne la schedule plus pendant 2s parce que l'utilisateur a décidé de changer de bureau, ... si l'appli en question doit jouer de son de manière continue, sa tache devient assez difficile...
Maintenant, tu peux faire la technique xine (enfin d'après ce que j'ai compris, xine fait ça, si ca se trouve j'ai super mal compris, merci de me corriger si je raconte n'importe quoi): tu lances 15 threads, t'as donc 15 fois plus de chance d'être schedulé en moins de x ms, tu es donc beaucoup moins affecté par d'eventuelles grosses irrégularités entre les instants ou tu es schedulé. Mais c'est de la triche :)
Si tu t'inquiete des perfs, tu peux tenter un gst-launch filesrc location="somefile.mp3" ! mad ! filesink location="somefile.uncompressed"
Ca te permettra de te donner une idée des performances de gstreamer en ce qui concerne la décompression d'un mp3 (j'ai pas testé, mais a priori ca met beaucoup moins de temps que la durée reel du mp3, et plus de temps qu'une appli spécialisée dans la lecture de mp3)
[^] # Re: Où en est Gstreamer ?
Posté par Alan_T . Évalué à 1.
Le principe des threads est de profiter au mieux des ressources d'une machine (qu'elle soit mono ou multi processeur, ou encore qu'elle possède un support à l'hyper-threading). Mais cela n'explique en rien pourquoi Gstreamer est lent... ou alors je n'ai pas compris.
Le fait que l'appli machin arrive à séparer la décompression vidéo en plusieurs threads concurrents montre seulement qu'elle est codée de manière plus intelligente que gstreamer (d'ailleurs, je ne suis pas sûr que gstreamer soit mono-threadé !!!). Mais, cela n'explique pas les saccades dans la lecture des fichiers audio ou vidéo.
Personnellement, je me base sur les logiciels i-Tunes et le display vidéo intégré dans gnome. Et, soit les deux applis sont programmées n'importe comment, soit gstreamer est totalement à revoir au niveau de la performance....
Enfin, pour ton exemple du mp3, je te signale que le fait qu'il traduise un fichier mp3 en moins de temps qu'il ne met à le jouer, montre simplement que le problème de gstreamer repose principalement au niveau du temps-réel. C'est à dire qu'il n'arrive pas à délivrer le son voulu au moment voulu... Donc, tout leur cinéma sur leur "low-latency" est à revoir... ce qui est possible d'ailleurs, mais je n'ai pas encore été voir le code...
[^] # Re: Où en est Gstreamer ?
Posté par Christophe Fergeau . Évalué à 1.
Et donc, si c'est tout de la faute de gstreamer, comment expliques-tu qu'il n'y ait plus de pb avec un noyau 2.6 ?
[^] # Re: Où en est Gstreamer ?
Posté par Alan_T . Évalué à 1.
Et puis, de toute façon, comme le faisait très justement remarquer quelqu'un d'autre, le 2.4 devrait suffire pour regarder un film. On le fait bien avec xine ou mplayer... pourquoi gstreamer aurait-il "besoin" d'un 2.6 ?
[^] # Re: Où en est Gstreamer ?
Posté par Christophe Fergeau . Évalué à 1.
C'est un autre problème alors ;) Toujours est-il que moi j'avais des pbs au temps du 2.4, et que maintenant c'est beaucoup mieux (faudrait que je refasse des tests approfondis pour être catégorique).
>On le fait bien avec xine ou mplayer... pourquoi gstreamer aurait-il "besoin" d'un 2.6 ?
Relis le thread 2/3 fois, j'aime pas trop me répéter... J'ai rien contre expliquer les points pas clairs dans ce que je raconte par contre ;)
[^] # Re: Où en est Gstreamer ?
Posté par Alan_T . Évalué à 1.
PS: C'est pas itune que j'utilise, c'est rhythmbox (autant pour moi)
[^] # Re: Où en est Gstreamer ?
Posté par Christophe Fergeau . Évalué à 1.
Par "tricher", je veux dire que c'est inutilement bourrin, et que c'est pas très joli. Ils sont redondants dans le sens où ils font la même chose, et leur seule raison d'être, c'est qu'un seul thread n'est pas suffisant pour obtenir une lecture fluide. Ca denote donc un certain manque au niveau de l'os si on est obligé de recourir à de telles techniques pour s'assurer des performances acceptables... (je me limite à la lecture de musique, j'y connais pas grand chose en vidéo, et en plus le support de vidéo dans gstreamer est moins avancé que le son).
Pour rhythmbox, si tu veux éviter les pb avec gstreamer, tu peux le recompiler pour qu'il utilise xine (c'est ce que je faisais au temps du 2.4)
Dans ton 2.6, t'as activé tout ce qui est preempt et low latency ?
[^] # Re: Où en est Gstreamer ?
Posté par Alan_T . Évalué à 1.
> xine (c'est ce que je faisais au temps du 2.4)
Ça je savait pas. Je vais essayer. Merci.
> Dans ton 2.6, t'as activé tout ce qui est preempt et low latency ?
Oui.
[^] # Re: Où en est Gstreamer ?
Posté par Christophe Fergeau . Évalué à 1.
Et avoir plusieurs threads qui se font concurrence pour faire exactement la même chose uniquement pour être sûr que le noyau daignera donner la main à l'appli avant qu'il ne soit trop tard, je n'appelle pas vraiment ça être « codée de manière plus intelligente que gstreamer » et « profiter au mieux des ressources d'une machine ». C'est uniquement un gros hack pas beau à mes yeux, même s'il a le mérite de très bien fonctionner d'un point de vue utilisateur (c'est assez malin aussi comme hack je trouve, mais ca ne le pas acceptable pour autant).
[^] # Re: Où en est Gstreamer ?
Posté par Daniel Caujolle-Bert . Évalué à 2.
Donc, d'apres ce que tu dis, xine lance plusieurs threads faisant la meme chose, tentant de bourrer le buffer de la carte son, par exemple, afin d'arriver dans les temps ?!
Désolé, tout faux ;-)
xine est multithreadé, chaque thread a une fonction (demultiplexage, sortie{audio,video},...).
Tu devrais jeter un coup d'oeil au code pour te donner une idée de la facon dont ca fonctionne.
--
[^] # Re: Où en est Gstreamer ?
Posté par Christophe Fergeau . Évalué à 1.
Comme je disais dans un message précédent :
> (enfin d'après ce que j'ai compris, xine fait ça, si ca se trouve j'ai super mal
> compris, merci de me corriger si je raconte n'importe quoi)
[^] # Re: Où en est Gstreamer ?
Posté par Nelis (site web personnel) . Évalué à 2.
C'est moi qui t'ai mal compris ou tu dis que remplir le buffer de la carte son c'est un hack pourri ? Sinon, peux-tu m'expliquer en quoi c'est mal ?
[^] # Re: Où en est Gstreamer ?
Posté par Christophe Fergeau . Évalué à 1.
[^] # Re: Où en est Gstreamer ?
Posté par Nelis (site web personnel) . Évalué à 1.
[^] # Re: Où en est Gstreamer ?
Posté par Alan_T . Évalué à 0.
[^] # Re: Où en est Gstreamer ?
Posté par Christophe Fergeau . Évalué à 2.
Mon message c'étiat pas "lancer plein de threads" sans rien après, c'était "lancer plein de threads qui s'occupent tous de remplir le buffer de la carte son en espérant qu'il y en ait un qui soit schedulé à temps"
Enfin on va pas épiloguer, perso je trouve ça tout pourri, toi tu as l'air de trouver ça particulièrement subtil et élégant, chacun ses gouts ;)
[^] # Re: Où en est Gstreamer ?
Posté par seedeexeen . Évalué à 1.
Ne me dis pas que tu trouve xine pourri à cause de ça, xine ne marche pas comme ça du tout.
Je sais que tu ne le dis pas mais c'est légerement insinué.
[^] # Re: Où en est Gstreamer ?
Posté par Christophe Fergeau . Évalué à 1.
[^] # Re: Où en est Gstreamer ?
Posté par Nelis (site web personnel) . Évalué à 1.
Je dis que lancer 15 threads faisant extactement la même chose dans l'optique "Y'en a bien un qui passera", ben c'est pas très propre ... Tu ne crois pas ?
[^] # Re: Où en est Gstreamer ?
Posté par seedeexeen . Évalué à 1.
c'est complètement faux !
xine c'est :
1 thread pour le demuxer
1 thread pour chaque decoder (1 audio + 1 video)
1 thread pour la sortie video
1 thread pour la sortie audio
+ d'autres pour le gui
Donc 1 thread chargé de remplir le buffer de la carte son.
[^] # Re: Où en est Gstreamer ?
Posté par Yusei (Mastodon) . Évalué à 1.
[^] # Re: Où en est Gstreamer ?
Posté par Alan_T . Évalué à 0.
Et il y a un patch, ou une version plus récente qui permet de corriger ce défaut ?
En tout cas merci ! Cela m'éclaire déjà plus que le "multi-threader c'est mal".
[^] # Re: Où en est Gstreamer ?
Posté par gnujsa . Évalué à 1.
Dommage, parce que QT (juk) sur un bureau non-KDE, c'est...
enfin, je préfère rien dire ;-)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.