Moi à la place des devels GStreamer je serais fier d'être utilisé par KDE alors que gstreamer était prévu pour GNOME!
Arf, mon explication devrait être très floue parcequ'en fait c'est l'inverse: les developpeurs de GStreamer pensaient que ce framework était prévu pour tout les DE (et ne se sont pas apperçu de certains aspects trop gnome-centrique puisqu'ils étaient tous devs gnome) ; ils sont plutot surpris d'apprendre que KDE ne l'adopte pas comme seul framework possible (à priori Phonon laissera le choix à l'utilisateur/distributeur du fw mm sous-jacent, gstreamer ou autre), et sont surpris de découvrir soudainement que les developpeurs de juk, amaroK etc. ont tu mal à maintenir leur backend GStreamer.
alors que jack qui est dans le même genre que gstreamer
En fait non. Jack est un serveur de son multipiste orienté temps réel (il fait du multiplexage, ce genre de choses). Il est plutôt de la famille de ESD ou aRts que de Gst en fait. Jack ne fait pas d'encodage/desencodage ogg/mp3 par ex.
Et GStreamer n'est pas un serveur de son. C'est un framework multimedia: il fournis une API unfiée pour parler aux serveurs de son comme aRts ou ESD (ou aux pilotes de la carte son directement), une API unifiée sur les différents codecs (audio, vidéo, sous-titres: ça évite d'avoir des structures totalement différentes dans son code selon qu'on accède à un fichier ogg ou a un mp3, par ex.), de synchronisation etc. Par contre il ne gère pas le multiplexage entre les accès audio concurents de diverses applis (rôle d'un serveur de son).
Btw il existe d'ailleur une tentative de plugin GStreamer offrant un backend sur jack (très experimental !).
Un exemple, pour situer tout ça. Imagine un lecteur audio :
- Il peut se charger lui même de lire les fichiers audio ogg, mp3, flac, wav, cd audios etc. et envoyer le résultat à Jack (ou à alsa, ou arts ...) pour le rendu sonore. Mais dans ce cas, il doit faire toutes les conversions (codecs -> pcm raw) lui meme (en s'adaptant à chaque fois aux API des différentes libs), et gérer lui même les accès au serveur de son (avec là encore leurs diférentes API: jack, esd, ...) ou à la carte son directement (API/interface différentes à chaque fois: alsa, win32, oss, mac os x, *bsd, solaris ...)
- Il peut utiliser un "framework multimedia" (comme GStreamer, xinelibs ou NMM) qui se chargera à sa place de deviner le codec utilisé (ogg, mp3, wav etc) de fournir à l'appli le son dans une structure de donnée "unifiée" (quel que soit le codec d'origine) de façon transparente. Le framework fournira éventuellement la possibilité d'appliquer des effets à ce son, encore une fois avec une API unifiée quelque soit la provenance des "effets" (native, LADSPA, ...). Enfin, le framework se chargera aussi d'envoyer le son au serveur de son / à la carte son / sur le réseau / ... pour le rendu, là encore, via une API unique malgrè la différence de chaque type de sortie possible.
- Il peut enfin utiliser un wrapper (type Phonon, quand il sera fait) qui permet d'écrire les besoins simples (lis tel fichier, enregistre telle source, envoi le son sur telle sortie ...) en peu de lignes dans l'application multimedia, et qui se charge de transformer ça en appels à un framework multimedia sous-jacent (GStreamern ou NMM etc). Celà permet notament de remplacer le framework multimedia s'il ne convient pas, sans rien modifier dans l'application.
Bref, pour situer shématiquement leurs positions relatives: Phonon fournis une couche d'abstraction/simplification au-dessus de GStreamer qui fournis une couche d'abstraction au-dessus de Jack.
Les frameworks comme GStreamer permettent d'éviter à chaque appli multimedia de ré-écrire le même code chacune de leur coté. Les wrappers comme phonon leur permettent d'être indépendants du choix du framework comme GStreamer ou xlinelibs (et de mutualiser ce code d'abstraction: qui est actuellement implémenté en double dans juk et amarok par ex.).
[^] # Re: précisions
Posté par herodiade . En réponse au journal Phonon et gstreamer : un voyage dans le temps. Évalué à 3.
Arf, mon explication devrait être très floue parcequ'en fait c'est l'inverse: les developpeurs de GStreamer pensaient que ce framework était prévu pour tout les DE (et ne se sont pas apperçu de certains aspects trop gnome-centrique puisqu'ils étaient tous devs gnome) ; ils sont plutot surpris d'apprendre que KDE ne l'adopte pas comme seul framework possible (à priori Phonon laissera le choix à l'utilisateur/distributeur du fw mm sous-jacent, gstreamer ou autre), et sont surpris de découvrir soudainement que les developpeurs de juk, amaroK etc. ont tu mal à maintenir leur backend GStreamer.
alors que jack qui est dans le même genre que gstreamer
En fait non. Jack est un serveur de son multipiste orienté temps réel (il fait du multiplexage, ce genre de choses). Il est plutôt de la famille de ESD ou aRts que de Gst en fait. Jack ne fait pas d'encodage/desencodage ogg/mp3 par ex.
Et GStreamer n'est pas un serveur de son. C'est un framework multimedia: il fournis une API unfiée pour parler aux serveurs de son comme aRts ou ESD (ou aux pilotes de la carte son directement), une API unifiée sur les différents codecs (audio, vidéo, sous-titres: ça évite d'avoir des structures totalement différentes dans son code selon qu'on accède à un fichier ogg ou a un mp3, par ex.), de synchronisation etc. Par contre il ne gère pas le multiplexage entre les accès audio concurents de diverses applis (rôle d'un serveur de son).
Btw il existe d'ailleur une tentative de plugin GStreamer offrant un backend sur jack (très experimental !).
Un exemple, pour situer tout ça. Imagine un lecteur audio :
- Il peut se charger lui même de lire les fichiers audio ogg, mp3, flac, wav, cd audios etc. et envoyer le résultat à Jack (ou à alsa, ou arts ...) pour le rendu sonore. Mais dans ce cas, il doit faire toutes les conversions (codecs -> pcm raw) lui meme (en s'adaptant à chaque fois aux API des différentes libs), et gérer lui même les accès au serveur de son (avec là encore leurs diférentes API: jack, esd, ...) ou à la carte son directement (API/interface différentes à chaque fois: alsa, win32, oss, mac os x, *bsd, solaris ...)
- Il peut utiliser un "framework multimedia" (comme GStreamer, xinelibs ou NMM) qui se chargera à sa place de deviner le codec utilisé (ogg, mp3, wav etc) de fournir à l'appli le son dans une structure de donnée "unifiée" (quel que soit le codec d'origine) de façon transparente. Le framework fournira éventuellement la possibilité d'appliquer des effets à ce son, encore une fois avec une API unifiée quelque soit la provenance des "effets" (native, LADSPA, ...). Enfin, le framework se chargera aussi d'envoyer le son au serveur de son / à la carte son / sur le réseau / ... pour le rendu, là encore, via une API unique malgrè la différence de chaque type de sortie possible.
- Il peut enfin utiliser un wrapper (type Phonon, quand il sera fait) qui permet d'écrire les besoins simples (lis tel fichier, enregistre telle source, envoi le son sur telle sortie ...) en peu de lignes dans l'application multimedia, et qui se charge de transformer ça en appels à un framework multimedia sous-jacent (GStreamern ou NMM etc). Celà permet notament de remplacer le framework multimedia s'il ne convient pas, sans rien modifier dans l'application.
Bref, pour situer shématiquement leurs positions relatives: Phonon fournis une couche d'abstraction/simplification au-dessus de GStreamer qui fournis une couche d'abstraction au-dessus de Jack.
Les frameworks comme GStreamer permettent d'éviter à chaque appli multimedia de ré-écrire le même code chacune de leur coté. Les wrappers comme phonon leur permettent d'être indépendants du choix du framework comme GStreamer ou xlinelibs (et de mutualiser ce code d'abstraction: qui est actuellement implémenté en double dans juk et amarok par ex.).