GStreamer : bientôt la version 1.0

Posté par (page perso) . Édité par Davy Defaud, Nÿco et baud123. Modéré par Davy Defaud. Licence CC by-sa
Tags :
42
28
nov.
2011
Audiovisuel

GStreamer est une bibliothèque logicielle de gestion du son et de l’image (c’est‐à‐dire un framework multimédia) disponible pour les systèmes GNU/Linux et ses cousins, Mac OS X, Windows et même Android. C’est aujourd’hui un pilier du projet GNOME (Totem, Rhythmbox, Epiphany, Gajim ou encore PiTiVi s’appuient dessus, pour citer quelques exemples). Le navigateur Web Opera l’utilise également pour diffuser des séquences audio‐vidéo en HTML 5 sur GNU/Linux, Mac OS X et Windows.

Logo de GStreamer

Le départ

GStreamer a été lancé en 1999 pour proposer une solution capable de concurrencer QuickTime (1991) et DirectShow (1996). Avec la série 0.8, lancée en mars 2004, GStreamer commence à s’approcher sérieusement de son but, que l’on peut considérer atteint avec la série 0.10 lancée peu après, en décembre 2005, et qui est toujours en vigueur aujourd’hui.

Développeurs, utilisateurs

Côté développeurs, alors qu’il a pu être reproché à un moment à cette bibliothèque d’être un peu trop bas niveau, des composants tels que playbin, camerabin, discoverer et encodebin ont été développés pour faciliter le développement d’applications. De la même façon, la bibliothèque a pu être enrichie de nombreux modules comme GNonLin et plus récemment gst-editing-services, qui sont destinés à faciliter la création d’éditeurs audio‐vidéo.

Côté utilisateur, je me souviens que, lorsque j’ai découvert Linux et GNOME à la fin 2005 en installant Ubuntu, les « forumeurs » conseillaient systématiquement d’installer la bibliothèque multimédia Xine en remplacement de GStreamer. Ces conseils ont disparu des forums maintenant que GStreamer est capable de décoder à peu près tout ce qui existe, ce qui illustre bien le chemin parcouru.

Version 1.0 en approche

Conçue pour être évolutive, la série 0.10 s’apprête donc à fêter son sixième anniversaire ! Toutefois, afin de permettre au projet de franchir une nouvelle étape, les développeurs ont décidé, en juillet 2009, au Gran Canaria Desktop Summit, de travailler parallèlement à une nouvelle mouture qui sera estampillée 1.0. Les plans de la future version 1.0 ont été publiés le 9 novembre 2010.

Trois rapports d’étape ont ensuite suivi :

La branche de développement devant mener à la version stable 1.0 a été estampillée 0.11, et la première version de développement (0.11.0) a été publiée le 2 août 2011 suivie d’une deuxième (0.11.1) le 29 septembre 2011.

Les bénéfices attendus de cette nouvelle version consisteraient, outre les classiques travaux de nettoyage de l’API existante, en une meilleure gestion mémoire et une meilleure exploitation des processeurs graphiques — GPU — et processeurs de signal numérique — DSP —, ces derniers étant particulièrement utiles dans le monde de l’embarqué.

GStreamer 1.0 devrait sortir à la fin de cette année, si tout va bien, et les développeurs espèrent que tous les modules seront portés vers cette nouvelle version dans le courant de l’année prochaine, idéalement d’ici le mois de juin 2012. Les applications elles‐mêmes devraient nécessiter peu, voire pas, d’adaptation pour tourner avec cette nouvelle version.

Les versions 0.10 et 1.0 pourront être installées parallèlement sur un même système, pour faciliter la transition.

  • # Xine, gstreamer puis ...

    Posté par (page perso) . Évalué à 10. Dernière modification le 28/11/11 à 17:01.

    J'avais migré de phonon-xine à phonon-gstreamer, mais reste que j'ai encore plein de fichiers audio mp3 et ogg que gstreamer lit mais sans sortir le moindre son...

    Du coup, je suis passé à phonon-vlc, dommage que gstreamer manque toujours de robustesse sur des fichiers vidéos mal branlés...

    Pour les fichiers ogg, c'est encodé avec grip y'a 12 ans sous Mandrake, je comprend vraiment pas pourquoi il fait chier...

    ps: trop bon, on peut modifier les commentaires!

    • [^] # Re: Xine, gstreamer puis ...

      Posté par (page perso) . Évalué à 2.

      J'avais migré de phonon-xine à phonon-gstreamer, mais reste que j'ai encore plein de fichiers audio mp3 et ogg que gstreamer lit mais sans sortir le moindre son...

      Tu as installé les machins ugly ?

      • [^] # Re: Xine, gstreamer puis ...

        Posté par (page perso) . Évalué à 2.

        J'ai dit plein, j'ai pas dit tous ;)

        C'est que sur certains fichiers donc c'est sur que y'a un bug mais je me vois mal comment faire un bug report légal dans un cas comme cela. Ou il faudrait connaitre un dev pour lui soumettre le fichier en privé.

        • [^] # Re: Xine, gstreamer puis ...

          Posté par (page perso) . Évalué à 6. Dernière modification le 28/11/11 à 18:12.

          Tu peux envoyer un fichier de log généré à la lecture de ton fichier. Voir la variable d'environnement GDT_DEBUG pour contrôler la verbosité des logs. Cela pourra peut être suffire à détecter le problème sans leur envoyer le fichier originel (et enfreindre les droits des auteurs).

          ps: pinaise, c'est bien vrai, on peut enfin modifier les posts !!! \o/ \o/ \o/

    • [^] # Re: Xine, gstreamer puis ...

      Posté par . Évalué à -3.

      Possible aussi que le bug soit dans l'interface entre phonon et gstreamer, plutôt que dans gstreamer direct.

    • [^] # Re: Xine, gstreamer puis ...

      Posté par . Évalué à 2.

      Je suis passé à phonon-mplayer que je compile depuis AUR (tu peux le trouver sur AFUR d’ailleurs, ou en activant le repo [archlinuxfr]).

  • # Pas encore au niveau de VLC

    Posté par . Évalué à 10.

    Malheureusement Gstreamer n'est pas encore au niveau de VLC. Quasiment aucun fichier vidéo ou audio ne résiste à VLC, là ou Gstreamer pêche encore beaucoup. Que ce soit avec des vidéos provenant d'un téléphone, appareil photo ou du net, Gstreamer me fait faux bond régulièrement.

    Gstreamer est vraiment pas mal, s'améliore c'est vrai, mais il n'y a pas encore de quoi désinstaller VLC, même en ayant tous les plugins good, bad, ugly, ffmpeg, BBC et bisounours que vous voulez.

    • [^] # Re: Pas encore au niveau de VLC

      Posté par . Évalué à 1.

      VLC est un lecteur multimédia, GStreamer un framework multimédia, la plupart du temps, VLC utilise FFmpeg pour décoder les formats multimédia. GStreamer fourni des décodeurs/encodeurs mais rien ne t'empêche de greffer un autre moteur, c'est déjà fait pour FFmpeg d'ailleurs.

      • [^] # Re: Pas encore au niveau de VLC

        Posté par (page perso) . Évalué à 10.

        Oui, enfin on parle d'un truc qui est sensé fonctionner, pas ou il faut se demander quel plugin il faut installer pour lire tel fichier... (avec des plugins qui font la meme chose).

        Et dire que libVLC n'est pas un framework multimedia, c'est quoi alors ?

        • [^] # Re: Pas encore au niveau de VLC

          Posté par . Évalué à 1.

          Et dire que libVLC n'est pas un framework multimedia, c'est quoi alors ?

          libVLC c'est du taillé sur-mesure pour un lecteur, ça n'a rien à voir avec un framework généraliste comme GStreamer. Certes, tu peux utiliser libVLC pour faire autre chose qu'un lecteur (ie: VLMC) mais ça n'a jamais été pensé pour, tu es très loin de la flexibilité d'un GStreamer.

          • [^] # Re: Pas encore au niveau de VLC

            Posté par (page perso) . Évalué à 10.

            En contrepartie, ça marche...

          • [^] # Re: Pas encore au niveau de VLC

            Posté par . Évalué à 2.

            La contrepartie de la flexibilité de GStreamer, ce sont les APIs imbitables.
            (et je dirais le manque de documentation, mais peut-être que ça a évolué depuis 2006 :-))

            • [^] # Re: Pas encore au niveau de VLC

              Posté par . Évalué à 4.

              La contrepartie de la flexibilité de GStreamer, ce sont les APIs imbitables.

              Je la trouve pas si compliquée que ça (pour une API C), c'est du GObject classique. Idem avec les wrappers C++, python.
              Par contre les concepts associés (éléments, pipelines etc ...), ça demande un effort de compréhension mais c'est plus ou moins les filtres unix appliqués au multimédia (et c'est la killer feature de GStreamer)

              (et je dirais le manque de documentation, mais peut-être que ça a évolué depuis 2006 :-))

              Maintenant les guides sont plutôt complets: http://gstreamer.freedesktop.org/documentation/
              L'API est à peu près documenté correctement, gst-inspect permet de récupérer les informations spécifiques à chaque élément, très pratique.

              • [^] # Re: Pas encore au niveau de VLC

                Posté par . Évalué à 4.

                Je la trouve pas si compliquée que ça (pour une API C), c'est du GObject classique. Idem avec les wrappers C++, python.

                En réalité j'ai utilisé les wrappers Python, qui non seulement n'étaient pas documentés, mais étaient aussi passablement buggés (mais c'était il y a 5 ans).

                Par contre les concepts associés (éléments, pipelines etc ...), ça demande un effort de compréhension mais c'est plus ou moins les filtres unix appliqués au multimédia (et c'est la killer feature de GStreamer)

                C'est un peu la vision "image d'Epinal". Les pipelines gstreamer sont beaucoup plus compliqués à comprendre que les filtres Unix. Quand un assemblage quelconque d'éléments se met à bloquer (ne démarre pas, par exemple), vas-y pour trouver quelle option doit être modifiée à quel endroit. A l'époque où j'ai utilisé gstreamer, essayer de comprendre comment ça fonctionne sous le capot tenait de la divination. La définition d'éléments personnalisés en Python fut une véritable horreur.

                Oui, le modèle est vraiment intéressant et flexible. Mais, à l'époque où je l'ai utilisé concrètement, j'ai eu envie de tuer quelques développeurs gstreamer à petit feu.

                • [^] # Re: Pas encore au niveau de VLC

                  Posté par . Évalué à 3.

                  Gstreamer 0.10.0 est sorti décembre 2005, donc en 2006, il y avait encore du Gstreamer 0.8 qui trainait (et qui je te l'accorde était très brouillon), et la doc peu complète.

                  C'est un peu la vision "image d'Epinal". Les pipelines gstreamer sont beaucoup plus compliqués à comprendre que les filtres Unix.

                  En même temps, les filtres unix traitent du texte, les éléments gstreamer des flux multimédias beaucoup plus complexes, donc forcément. C'est surtout par rapport aux autres frameworks multimédias que le gain est appréciable.

                  Avec GStreamer, des utilisations avancées des flux multimédias sont accessibles à des non-spécialistes avec un peu d'effort. Je connais aucun autre framework multimédia qui soit autant extensible, flexible et productif, avec gst-launch, tu peux faire un POC en quelques minutes pour valider une idée, écrire des éléments propres à ton pipeline est bcp plus simple que de le faire avec FFmpeg ou xine, etc ... Oui, GStreamer n'est pas parfait, il n'a pas autant de maturité que ses concurrents mais c'est le couteau suisse.

                • [^] # Re: Pas encore au niveau de VLC

                  Posté par . Évalué à 2.

                  Quand un assemblage quelconque d'éléments se met à bloquer (ne démarre pas, par exemple), vas-y pour trouver quelle option doit être modifiée à quel endroit.

                  Tu lances ton pipeline avec gst-launch et l'option -v, et tu as plus d'infos, notamment l'élément sur lequel ça râle.

                  Et pour aller encore plus loin, tu peux créer la variable GST_DEBUG avec la valeur 3.

                  Je te l'accorde, la doc est brouillonne, mais une fois qu'on connait les trucs, ça s'utilise relativement bien. C'est comme tout faut prendre le temps (même si c'est plus difficile sans bon tutorial).

                  Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

    • [^] # Re: Pas encore au niveau de VLC

      Posté par . Évalué à 4.

      Et puis bon, les players utilisants Gstreamer ne sont pas fantastique.
      Pour ne citer que totem, c'est un truc qui est pas du tout réactif et qui n'arrive a ouvrir quelques fichiers.

      mplayer et vlc sont le paradis a coté.

      [quote]
      GStreamer a été lancé en 1999 pour proposer une solution capable de concurrencer QuickTime (1991) et DirectShow (1996). Avec la série 0.8, lancée en mars 2004, GStreamer commence à s’approcher sérieusement de son but, que l’on peut considérer atteint avec la série 0.10 lancée peu après, en décembre 2005, et qui est toujours en vigueur aujourd’hui.
      [quote]

      Franchement dire que GStreamer concurrence QuickTime ou DirectShow c'est ce foutre de la geule du monde.

      Qu'on compare le nombre de soft/utilisateur de chacun de ces frameworks.

      PS : quand j'avais regardé les API de Gstreamer il y a quelques temps (5 ans), ça faisait bonne usine à gaz.

      • [^] # Re: Pas encore au niveau de VLC

        Posté par (page perso) . Évalué à 1.

        Pour ne citer que totem, c'est un truc qui est pas du tout réactif et qui n'arrive a ouvrir quelques fichiers.

        Ah ? Pas du tout réactif ? Par rapport à vlc qui met une plombe à se lancer et presque autant à se déplacer dans un fichier, je trouve totem rapide.

        Pour les quelques fichiers qu'il n'arrive pas à ouvrir, ils sont de quel genre ?

        • [^] # Re: Pas encore au niveau de VLC

          Posté par . Évalué à 2.

          Vlc ne met pas plus de temps à se lancer que Totem.
          Par contre c'est vrai que vlc supporte plus de formats.

          • [^] # Re: Pas encore au niveau de VLC

            Posté par . Évalué à 8.

            Par rapport à vlc qui met une plombe à se lancer et presque autant à se déplacer dans un fichier, je trouve totem rapide.

            Vlc ne met pas plus de temps à se lancer que Totem.

            Un Gnomiste et un KDEiste qui discutent?

            THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

            • [^] # Re: Pas encore au niveau de VLC

              Posté par (page perso) . Évalué à 4.

              Un Gnomiste et un KDEiste qui discutent?

              Ou peut etre un archlinuxiste ? Je comprend pas, sur ma arch, vlc met trois plombes à se lancer alors que sous Kubuntu c'est très rapide, j'ai tout essayé sans succès... Comprend pas :-/

              • [^] # Re: Pas encore au niveau de VLC

                Posté par . Évalué à 2.

                Ou peut etre un archlinuxiste

                Je sais que c’était pour rester dans les rimes en -iste, mais on dit un Archer :)

              • [^] # Re: Pas encore au niveau de VLC

                Posté par . Évalué à 2.

                Je suis en debian testing sous Gnome 3 ( mais peut-être plus pour longtemps vu que Gnome 3 m'horripile ) et vlc se lance très rapidement. Visuellement il n'y a pas de différence avec le lancement de totem.

          • [^] # Re: Pas encore au niveau de VLC

            Posté par . Évalué à 0.

            Par contre c'est vrai que vlc supporte plus de formats.

            C'est surtout faux.

            • [^] # Re: Pas encore au niveau de VLC

              Posté par (page perso) . Évalué à 6.

              Par support, il veut dire qui segfault pas un fichier vidéo sur deux.

              • [^] # Re: Pas encore au niveau de VLC

                Posté par . Évalué à 1.

                J'ai souvent eu des fichiers qui se lisaient pas (souvent, ils restent blo à un moment donné) mais je n'ai jamais eu de segfault.

                • [^] # Re: Pas encore au niveau de VLC

                  Posté par (page perso) . Évalué à 3.

                  ça m'est arrivé avec gstreamer, il n'y a pas longtemps, sous Mageia. Pour regarder un film avec des amis, j'ai installé tous les codecs disponibles. Manque de bol, ça crashait dès que je tentais de lire le film... J'ai dû trouver le codec fautif et le désinstaller. Et il n'était même pas requis pour lire la vidéo. J'ai un a priori positif sur GStreamer, mais ça m'a un peu refroidi.

                  Au final, on a commencé à regarder le film tard, et on l'a jamais fini...

                  • [^] # Re: Pas encore au niveau de VLC

                    Posté par . Évalué à 10.

                    Alors que tu aurais pu utiliser mplayer...

                    • [^] # Re: Pas encore au niveau de VLC

                      Posté par . Évalué à 5.

                      Ou VLC. Putain pour une fois que l'on a un super soft bien franchouillard profitons en!

                      • [^] # Re: Pas encore au niveau de VLC

                        Posté par (page perso) . Évalué à 3.

                        VLC a l'interface utilisateur la plus repoussante qu'il m'ait été donné de voir sur un logiciel grand public. C'est pour cette raison que je n'utilise quasiment jamais VLC. Quant à mplayer... Bin non, j'aime bien Totem, moi.

                        • [^] # Re: Pas encore au niveau de VLC

                          Posté par (page perso) . Évalué à 5.

                          Le mercredi 30 novembre 2011 à 17:15 +0100, liberforce a écrit :
                          > Quant à mplayer...

                          mplayer nomdufichier

                          C'est relativement simple comme interface.

                        • [^] # Re: Pas encore au niveau de VLC

                          Posté par . Évalué à 6.

                          Son interface CLI est ignoble, mais l'interface Qt4 n'est pas si mauvaise.
                          mplayer c'est le contraire son interface graphique est minimaliste ^^, mais la partie CLI est bien faite et le manipuler au clavier pendant la lecture est très intuitif (et pratique quand on est sur un netbook dans le train).

                          Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

                          • [^] # Re: Pas encore au niveau de VLC

                            Posté par . Évalué à 3.

                            le manipuler au clavier pendant la lecture est très intuitif

                            Je suis un grand fan de MPlayer (je n’utilise que ça) mais je peux pas te laisser dire ça.

                            Effectivement, c’est énorme de pouvoir tout faire avec le clavier, mais ce n’est pas intuitif de faire « j » pour changer de sous-titre, « # » pour changer de piste audio, « _ » pour changer de piste vidéo, « * » et « / » pour augmenter diminuer le volume, etc.

                            Par contre, l’interface de SMPlayer est assez pourri comme toutes les interfaces graphiques des logiciels de lecture vidéo.

                        • [^] # Re: Pas encore au niveau de VLC

                          Posté par (page perso) . Évalué à 8.

                          VLC a l'interface utilisateur la plus repoussante qu'il m'ait été
                          donné de voir sur un logiciel grand public

                          Et comme le grand public c'est des cons, tout le monde utilise VLC... Normal quoi... Et bizarrement, si y'a bien un logiciel ou l'on vient jamais me faire chier, c'est VLC, bizarre...

                          • [^] # Re: Pas encore au niveau de VLC

                            Posté par . Évalué à 5.

                            Je ne peux t'approuver. Le nombre de fois ou je vois en meeting et conference l'icone VLC sur des Mac et des windows c'est enorme en fait c'est plutot l'inverse qui est super rare: ne pas la voir.
                            Perso je ne trouve pas son interface si complique. Play/pause/avance et volume controle c'est si difficile que ca a apprehender?

                            • [^] # Re: Pas encore au niveau de VLC

                              Posté par . Évalué à 3.

                              Je ne peux t'approuver.

                              Soit il manque un mot ('que'), soit tu n'est pas d'accord avec lui... Mais en fait tu l'es ! Car son propos est ironique et fait remarquer que si tout le monde utilise VLC (alors qu'il n'est jamais fourni par défaut), c'est sans doute pas pour rien...

                          • [^] # Re: Pas encore au niveau de VLC

                            Posté par (page perso) . Évalué à 1.

                            Si VLC a percé au niveau du grand public, c'est parce que le grand public ne sais pas installer des codecs. Le grand public veut installer le bouzin, ouvrir sa vidéo, et paf, ça marche et il peut regarder sa série à la con. Et c'est exactement ce que VLC fait.

                            D'ailleurs au boulot sous Windows, j'utilise moi même VLC, parce que c'est le meilleur lecteur sur cette plate-forme: il lit tout les formats sans effort, il lit vraiment tout, super, youpi ! Sauf que...

                            L'interface est tout de même à chier.

                            Mais les cons du grand public sont sous Windows, c'est pas comme s'ils pouvaient se rendre compte quand une interface était pourrie. Après tu me diras qu'il y a des utilisateurs de VLC sous Linux. Ce à quoi je te répondrai que chacun a ses perversions...

                            • [^] # Re: Pas encore au niveau de VLC

                              Posté par . Évalué à 4.

                              Et sinon des arguments, tu en as ou tu préfère te contenter de répéter invariablement la même chose.

                              De plus je crois que VLC est thémable, si tu as cet avis et s'il si évident que tu n'a pas à l'argumenté, il est probable que d'autres aient eu la même idée.

                              Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

                      • [^] # Re: Pas encore au niveau de VLC

                        Posté par . Évalué à 1.

                        L'auteur de Totem est français aussi.

                        • [^] # Re: Pas encore au niveau de VLC

                          Posté par (page perso) . Évalué à 2.

                          Bastien ne s'est pas fait naturaliser anglais ?

                          • [^] # Re: Pas encore au niveau de VLC

                            Posté par . Évalué à -1.

                            Ben la France on l'aime ou on la quitte, si j'ai bien compris.

                            • [^] # Re: Pas encore au niveau de VLC

                              Posté par . Évalué à 2.

                              on peut aimer la France et vouloir etre autre chose que chomeur? Cela ne fait pas parti des possibilites?

                              • [^] # Re: Pas encore au niveau de VLC

                                Posté par . Évalué à 1.

                                Pour info c'était de l'humour.

                                Pour ma part je ne suis pas français, mais en l'occurence je ne crois pas que la France soit peuplée de chômeurs, et il n'est certainement pas non plus nécessaire de se faire naturaliser pour travailler à l'étranger.

                                • [^] # Re: Pas encore au niveau de VLC

                                  Posté par . Évalué à 1.

                                  La france n'est certainement pas peuple de chomeurs mais parfoit c'est plus difficile de trouver du travail si l'on refuse de bouger et en particulier si on ne veut pas partir a l'etranger.
                                  Enfin bon pas grave.

            • [^] # Re: Pas encore au niveau de VLC

              Posté par . Évalué à 2.

              Par défaut les vidéos se lancent dans Totem avec gstreamer. Quand ça ne marche pas j'essaie avec vlc qui en général fonctionne et quand ça ne fonctionne toujours pas je finis avec mplayer. Si ce dernier échoue je laisse tomber.

      • [^] # Re: Pas encore au niveau de VLC

        Posté par (page perso) . Évalué à 2.

        Et puis bon, les players utilisants Gstreamer ne sont pas fantastique.
        Pour ne citer que totem, c'est un truc qui est pas du tout réactif et qui n'arrive a ouvrir quelques fichiers.

        C'est vrai que Totem manque un peu d'intérêt (à part pour son thème GTK sombre, peut-être). Mais pour ce qui est des lecteurs de bibliothèque musicale comme Rhythmbox, je suis davantage satisfait ; il n'y a bien qu'une poignée de WMA rippés en 2001 (et j'ai toujours le CD en plus) qui résiste encore à GStreamer, et en me contentant des "good", "bad" et "ugly". Même Arista et Transmageddon marchent pas trop mal.

        En revanche, j'ai du mal à me rappeler à quoi servent les plugins du genre "ffmpeg" (ça remplace tous les autres ?) ou "fluendo" (qui ça ?).

        • [^] # Re: Pas encore au niveau de VLC

          Posté par . Évalué à 2.

          FFMPEG, c'est en plus.
          Avant il était inclut par défaut, mais vu sa taille, il été séparé dans un paquet séparé.
          Avec FFMpeg + ugly + good + bad + ugly-multiverse + bad-multiverse , je lis plus de fichiers que Vlc.
          Je n'ai jamais eu de plantage, mais j'utilise Totem, qui est simplement légé et rapide pour peu qu'on soit sous gnome.

          • [^] # Re: Pas encore au niveau de VLC

            Posté par (page perso) . Évalué à 5.

            Avec FFMpeg + ugly + good + bad + ugly-multiverse + bad-multiverse

            Y'a que moi pour trouver que ça ne ressemble à rien tout ça ? surtout ugly, bad, c'est quoi ce merdier ?
            Ce qui est sur c'est que c'est pas le genre de truc qui donne envie d'utiliser GStreamer.

            • [^] # Re: Pas encore au niveau de VLC

              Posté par (page perso) . Évalué à 1.

              C'est transparent pour l'utilisateur avec l'installation automatique des codecs.
              C'est les coulisses, t'es pas obligé d'y aller pour apprécier le spectacle !

              • [^] # Re: Pas encore au niveau de VLC

                Posté par (page perso) . Évalué à 2. Dernière modification le 29/11/11 à 15:12.

                Ben étant donné qu'une vraiment grosse partie des commentaires en parle, je suis perplexe sur le côté "automatique" et surtout transparent de la chose.
                D'ailleurs comment ça automatique ? Si j'installe pas le paquet, il ne va pas venir par magie sans me le demander, si ?

                • [^] # Re: Pas encore au niveau de VLC

                  Posté par (page perso) . Évalué à 1.

                  Sous Ubuntu ou Debian par exemple, il te prévient qu'il doit installer des codecs supplémentaires pour lire le fichier et hop :-)

                • [^] # Re: Pas encore au niveau de VLC

                  Posté par (page perso) . Évalué à 4.

                  Le mardi 29 novembre 2011 à 15:11 +0100, CrEv a écrit :
                  > il ne va pas
                  > venir par magie sans me le demander, si ?

                  il me semble que c'est géré par gstreamer-codec-install

                • [^] # Re: Pas encore au niveau de VLC

                  Posté par (page perso) . Évalué à 1.

                  Sous Fedora, il t'informe qu'il manque des codecs. Et si tu lui dit oui il va automatiquement les chercher et les installer (bon il les trouvera seulement si tu as le dépôt RPMfusion, mais ça a rien à voir avec Gstreamer)

                  Matthieu Gautier|irc:starmad

        • [^] # Re: Pas encore au niveau de VLC

          Posté par (page perso) . Évalué à 5. Dernière modification le 29/11/11 à 15:15.

          "C'est vrai que Totem manque un peu d'intérêt"

          Perso je suis fan absolu de Totem qui me lit tout (comme VLC) y compris des WMV ou des vidéos encapsulées Flash (mais j'ai pitet pas autant de fichiers exotiques que d'autres).

          Le point fort de Totem, à l'image de GNOME, est que ça marche direct. J'ai pas à choisir l'une des 5 options de désentrelacement, à me perdre dans des menus alambiqués... La lecture reprend où elle s'est arrêtée, il y a même un plugin YouTube. Bref il fait le Job :-)

          • [^] # Re: Pas encore au niveau de VLC

            Posté par (page perso) . Évalué à 2.

            Le mardi 29 novembre 2011 à 15:12 +0100, antistress a écrit :
            > La lecture reprend où elle s'est arrêtée

            ça c'est cool, y'a une option pour faire ça avec mplayer ?

            • [^] # Re: Pas encore au niveau de VLC

              Posté par . Évalué à 5.

              Smplayer le fait, avec le téléchargement auto des sous-titres, le recalage des sous-titres en une touche (fonction "affiche la prochaine/précédente ligne de texte maintenant", a appliquer dès que le personnage se met à parler), etc...

          • [^] # Re: Pas encore au niveau de VLC

            Posté par . Évalué à 3.

            Si y a pas de menus très compliqués, les gens croient que l'application sait rien faire -_-"
            J'apprécie bcp VLC, mais l'ergonomie de l'interface graphique par défaut est clairement pourrie (et encore ça s'est amélioré lors du passage à Qt4).

            Totem marche pas trop mal, il sait récupérer les sous titres, il sait lire des vidéos sur un partage daap, du DVB (avec gnome-dvb-daemon entre autre mais ça manque un peu d'intégration). Il juste marche, pour 99% des utilisateurs.

            • [^] # Re: Pas encore au niveau de VLC

              Posté par (page perso) . Évalué à 2.

              quand je clique déplace les titres dans la liste de lecture de totem il supprime ce qu'il y avait déjà (super, j'adore !) et il ne classe pas les titres dans l'ordre (super pénible, surtout quand dans le nom de fichier des chansons commence par le numéro...)

              bref, c'est pas super ergonomique

          • [^] # Re: Pas encore au niveau de VLC

            Posté par (page perso) . Évalué à 2. Dernière modification le 05/12/11 à 01:32.

            Autre avantage de Totem qui lit déjà les vidéos encapsulées en Flash : un plugin (Vegas) pour navigateurs Web vient de sortir (utilisant libquvi) pour lire les vidéos embarquées de toute une série de sites, sans avoir à installer le vilain greffon Flash
            http://www.hadess.net/2011/12/vegas-baby.html
            http://git.gnome.org/browse/totem/commit/?id=bd1d1eb17478eb5ad61909c4005258238f7953a0

    • [^] # Re: Pas encore au niveau de VLC

      Posté par . Évalué à 7.

      À mon avis, le gros plus de GStreamer est sa notion de pipeline pour travailler sur des fichiers audio et vidéos.

      Avec ça, on peut faire du montage avec filtres depuis plusieurs sources et sortir vers plusieurs cibles, le tout avec une seule ligne de commande.

      Ça parait complexe, mais faire la même chose avec FFmpeg, VLC ou Mencoder est clairement à plusieurs niveau de difficulté en plus (si c'est possible).

      Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

      • [^] # Re: Pas encore au niveau de VLC

        Posté par (page perso) . Évalué à -1.

        Ça parait complexe, mais faire la même chose avec FFmpeg, VLC ou
        Mencoder est clairement à plusieurs niveau de difficulté en plus (si
        c'est possible).

        T'as oublié la balise humour j'espere ?

        ffmpeg et mencoder font la meme chose en une ligne de commande et sans utiliser un syntaxe imbitable...

        • [^] # Re: Pas encore au niveau de VLC

          Posté par . Évalué à 7.

          Tu as déjà vu des pipelines Gstreamer ?

          Avec ça, tu peux utiliser plusieurs vidéos sources, pour les mixer en une seule en appliquant des filtres, et enregistrer le résultat à plusieurs endroits avec à chaque fois des paramètres d'encodage différents, le tout en affichant des aperçus en même temps. Et je le répète, avec une seule ligne de commande.

          J'ai cherché avec Mencoder et FFmpeg, mais ça ne va pas aussi loin.

          Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

        • [^] # Re: Pas encore au niveau de VLC

          Posté par (page perso) . Évalué à 10. Dernière modification le 29/11/11 à 19:33.

          Exemple de cas d'utilisation Gstreamer...

          Faire une connexion audio (duplex stéréo 48k) par internet, avec un petit buffer de 60ms pour gérer la gigue et laisser aux paquets en retard le temps d'arriver.
          Transport : RTP sur UDP
          Codec : CELT

          sur chacun des PCs :

          #! /bin/sh
          HOSTNAME='moncopain'
          
          AUDIO_CHANNELS='2'
          AUDIO_RATE='48000'
          
          CELT_BITRATE='128'
          CELT_FRAMESIZE='64'
          
          RTP_BUFFER_LATENCY='60'
          
          # sender
          gst-launch-0.10 -v alsasrc ! audioconvert  audioresample \
          	! "audio/x-raw-int,rate=$AUDIO_RATE,width=16,channels=$AUDIO_CHANNELS" \
          	! celtenc cbr=true bitrate=$CELT_BITRATE framesize=$CELT_FRAMESIZE \
          	! rtpceltpay ! udpsink host=$HOSTNAME \
          & PID_SENDER=$!
          
          # the received stream
          caps="application/x-rtp, media=(string)audio, clock-rate=(int)$AUDIO_RATE, encoding-name=(string)CELT, encoding-params=(string)$AUDIO_CHANNELS, frame-size=(string)480, payload=(int)96"
          
          # receiver
          gst-launch-0.10 -v udpsrc caps="$caps" \
          	! gstrtpjitterbuffer latency=$RTP_BUFFER_LATENCY \
          	! rtpceltdepay ! celtdec ! audioconvert ! audioresample ! alsasink \
          & PID_RECEIVER=$!
          
          # trap SIGINT (2) then kill gstreamer process then exit
          trap "kill $PID_SENDER $PID_RECEIVER; exit" 2
          
          # wait infinitly
          cat > /dev/null
          
          

          C'est une réduction d'un script plus complexe dans lequel je précise quelle interface audio capturer/lire, quelle interface réseau écouter, quel port envoyer et écouter, etc. etc. mais on pourrait le simplifier encore beaucoup.
          La variable caps est en fait fournie dans la sortie standard de la première commande, donc il n'y a même pas l'argument "comment je devine cette variable ?". et tout le reste des options je les ai trouvées avec gst-inspect (je pose la question, il me répond, c'est ce que j'attends d'une IHM).

          Mplayer ne sait pas faire cela.
          Avec VLC on pourra peut-être un jour, ça fait un peu de RTP mais pour très peu de codecs (du RTP an mpga, plus 3secondes de latences, arg). Et la syntaxe est vraiment imbitable : quand je travaille avec VLC, je lance la gui, je cliquouille, et je copie les lignes de commandes qu'il construit (et qu'il a le bon goût de fournir).
          Je suis incapable d'écrire une ligne similaire dans la syntaxe VLC, je n'en ai simplement pas le courage car gstreamer est tellement limpide à coté, et tellement plus efficace ! C'est dommage parceque L de VLC signifie Lan, c'est pourquoi naïvement je m'étais d'abord tourné vers VLC avant de découvrir, avec joie, Gstreamer !

          Avec un script comme cela, j'ai une qualité similaire, une latence aussi courte (se chiffre en ms) et un débit aussi raisonnable que les codecs IP qu'on trouve dans le commerce à 2000€. Encapsulé dans un OpenVPN, je transporte avec ça, IRL, de vraies émissions pour une radio FM en direct de n'importe où il y a Internet (la dernière a duré deux heures sur un salon). Je suis aussi en train de mettre en place un duplex entre deux studios (100km de distance). D'autres travaillent du son à distance avec ça (et l'écran en VNC).

          Je donne cet exemple, mais on peut en trouver plein d'autres, Gstreamer c'est plus que de la lecture de fichiers multimédia et le divertissement de le cadre privé de la famille. Il y a des gens qui travaillent grâce à cette trentaine de lignes de code (que je saurais réduire à deux, mais peut-être que des plus malins que moi sauront réduire cela à une seule) et Gstreamer.

          Chez moi, gst-inspect-0.10 -a me dit à la fin de 115746 lignes de documentations :
          Total count: 226 plugins (1 blacklist entry not shown), 1397 features

          On peut en faire des choses !

          (et puis pour le moment, c'est mon seul moyen de coder en vp8 avec les distribs que j'utilise).

          ce commentaire est sous licence cc by 4 et précédentes

          • [^] # Re: Pas encore au niveau de VLC

            Posté par (page perso) . Évalué à 2.

            On peut en faire des choses !

            Et quand tu veux faire des choses qui servent dans la vie de tous les jours sans apprendre une syntaxe imbitable, ben tu utilises ffmpeg, merci de confirmer ce que je pensais ;)

            • [^] # Re: Pas encore au niveau de VLC

              Posté par . Évalué à 5.

              Je dois avouer que pour mes besoins très simples, extraire du son et le convertir en mp3 d'un fichier vidéo dans un conteneur flash, je suis bien content de faire un simple :

              ffmpeg -i fichier.flv fichier.mp3
              
              

              Plutôt que des trucs alambiqués en vlc (ce trucs est vraiment une horreur à manipuler !) ou gstreamer. mencoder n'est pas très compliqué (et il a une syntaxe respectueuse des conventions en shell), mais est un peu plus compliqué.

              Au pire si je veux garder le même format que celui inclus j'utilise mediainfo pour voir les caractéristiques de mon format.

              Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

              • [^] # Re: Pas encore au niveau de VLC

                Posté par . Évalué à 4.

                Ben explique-moi ce qu'il y a d'alambiqué dans ceci :

                $ gst-launch filesrc location='fichier.flv' ! decodebin ! audioconvert ! lame bitrate=128000 ! filesink location='fichier.mp4' 
                
                

                C'est certes plus long, mais c'est lisible et chaque élément a un rôle précis. En plus ça ressemble énormément à des pipelines Unix, il faut le reconnaître. Au passage, ça conserve les tags ID3, ce que ne fait pas FFmpeg.

                Si la syntaxe FFmpeg est ici plus simple, c'est que l'exemple lui-même est très simple. Dès que tu compliques un peu, ça devient largement illisible et je dois sortir sans cesse la manpage.

                Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

                • [^] # Re: Pas encore au niveau de VLC

                  Posté par . Évalué à 2.

                  Ton exemple est extrêmement pertinent. Je comprends et serais, je pense, capable de faire des modif' rien qu'à la lecture de ta commande.

                  Je t'avoue que quand j'ai commencé à faire cela, la question de gstreamer ne s'est même pas posée parce que je ne savais tout simplement pas qu'il possédait une interface en CLI.

                  Je suis tout de même surpris par la partie :

                  audioconvert ! lame bitrate=128000
                  
                  

                  Que j'aurais bien vu sans ! (je vois lame plus comme une option/commande d'audioconvert qu'autonome).

                  Au passage, ça conserve les tags ID3, ce que ne fait pas FFmpeg.

                  C'est un point important à prendre en compte.

                  Si la syntaxe FFmpeg est ici plus simple, c'est que l'exemple lui-même est très simple. Dès que tu compliques un peu, ça devient largement illisible et je dois sortir sans cesse la manpage.

                  Justement pour faire quelque chose d'aussi simple qu'extraire un fichier audio à partir d'un fichier vidéo, on cherche à ne pas dégainer tout un arsenal.

                  J'aurais enfin une question à poser :

                  • ton exemple réencode l'audio (ce que fait aussi ffmpeg), est-il possible de ne pas de le faire et de le garder tel quel ? (je ne sais pas si c'est techniquement possible d'une manière général).
                  • gstreamer gérant la vidéo est-il possible de lui faire ripper un dvd ? (si c'est le cas je serais vraiment heureux)

                  En tout cas merci

                  Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

                  • [^] # Re: Pas encore au niveau de VLC

                    Posté par . Évalué à 2.

                    Je t'avoue que quand j'ai commencé à faire cela, la question de gstreamer ne s'est même pas posée parce que je ne savais tout simplement pas qu'il possédait une interface en CLI.

                    Officiellement, gst-launch est destiné aux développeurs pour tester leurs pipelines donc pas mis en avant, mais c'est en fait aussi pratique pour les power-users.

                    Je suis tout de même surpris par la partie :

                    audioconvert ! lame bitrate=128000

                    Que j'aurais bien vu sans ! (je vois lame plus comme une option/commande d'audioconvert qu'autonome).

                    Oui, c'est l'un des points subtils de Gstreamer : le audioconvert ne convertit pas le flux vers un format au sens propre, il le convertit pour qu'il soit utilisable dans l'espace de travail de Gstreamer. On pourrait dire que ça fait partie de la phase de lecture.

                    Tu as la même chose pour la vidéo avec ffmpegcolorspace.

                    Justement pour faire quelque chose d'aussi simple qu'extraire un fichier audio à partir d'un fichier vidéo, on cherche à ne pas dégainer tout un arsenal.

                    Pas faux, mais j'apprécie d'avoir un seul outil très puissant pour tous les usages plutôt qu'une multitude d'outils chacun moins puissants. Et comme on dit qui peut le plus peut le moins : à l'usage, je n'ai pas l'impression d'utiliser un outil surdimensionné.

                    ton exemple réencode l'audio (ce que fait aussi ffmpeg), est-il possible de ne pas de le faire et de le garder tel quel ? (je ne sais pas si c'est techniquement possible d'une manière général).

                    Oui, il faut démultiplexer et non décoder, ce que fait flvdemux (et de manière générale les *demux) :

                    filesrc location='fichier.flv' ! flvdemux ! audio/mpeg ! filesink location='fichier.mp3'
                    
                    

                    Au passage, le « audio/mpeg » le force à sélectionner le flux MP3, sinon il prend le premier, souvent la vidéo.

                    gstreamer gérant la vidéo est-il possible de lui faire ripper un dvd ? (si c'est le cas je serais vraiment heureux)

                    Là aussi c'est possible même avec les sous-titres avec dvdreadsrc et dvdemux. La partie la plus sioux est la sélection des pistes, mais d'habitude je fais ça avec decodebin sans sortie et l'option -m de gst-launch.

                    Voici un exemple de mémoire, il y a peut-être des adaptations à faire :

                    dvdreadsrc device='image.iso' title=1 ! dvddemux name=d.
                    
                    	d.video_00 ! queue ! decodebin ! ffmpegcolorspace ! vp8enc mode=vbr quality=8 ! m.
                    	d.audio_00 ! queue ! decodebin ! audioconvert ! vorbisenc quality=0.6 ! m.
                    	d.subtitles_00 ! queue ! kateenc language-code=fr category=spu-subtitles ! m.
                    	
                    	matroskamux name=m ! filesink location='out.mkv'
                    
                    

                    Tu peux aussi te contenter d'une image MPEG de tous les flux :

                    dvdreadsrc device='image.iso' title=1 ! filesink location='out.mpeg'
                    
                    

                    Après, tu peux mettre des filtres comme audioresample, videoscale, ou videorate, ou même insérer des métadonnées avec taginject (pour le titre, la langue, etc). Ici, gst-inspect est ton ami :-)

                    Dans tous les cas, je trouve que c'est très lisible une fois qu'on a pigé le concept des pipelines.

                    Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

                    • [^] # Re: Pas encore au niveau de VLC

                      Posté par . Évalué à 3.

                      Pas faux, mais j'apprécie d'avoir un seul outil très puissant pour tous les usages plutôt qu'une multitude d'outils chacun moins puissants. Et comme on dit qui peut le plus peut le moins : à l'usage, je n'ai pas l'impression d'utiliser un outil surdimensionné.

                      En principe dans le monde du libre on a accès à des outils très puissants (sans pirater). Généralement quand je dois en utiliser, je commence par chercher à la louche celui qui sera le plus simple, puis au fur et à mesure des besoins je me repose la question « Est-ce que l'outil reste pertinent ? ».

                      Dans tous les cas, je trouve que c'est très lisible une fois qu'on a pigé le concept des pipelines.

                      Je trouve qu'il n'est pas moche. Je regarderais la doc quand j'en aurait le temps pour faire de ripping de DVD ça m'a l'aire bien sympa.

                      Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

                • [^] # Re: Pas encore au niveau de VLC

                  Posté par . Évalué à 2.

                  Au passage, ça conserve les tags ID3, ce que ne fait pas FFmpeg.

                  Je dirai que c’est faux. Dans mon souvenir, ffmpeg -i koin.flac koin.mp3 conserve les tags.

                  • [^] # Re: Pas encore au niveau de VLC

                    Posté par . Évalué à 1.

                    Bah dans le mien justement non. Après, ça a peut-être changé, je vais réessayer.

                    Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

              • [^] # Re: Pas encore au niveau de VLC

                Posté par (page perso) . Évalué à 4.

                Si je reprends mon exemple, j'aurai aussi pu me passer de gstreamer, avec un truc qui parait bien plus simple avec arecord/aplay, netcat et celtenc/celtdec

                arecord -f dat --file-type raw | celtenc --16bit --rate 48000 --stereo --bitrate 256 --framesize 64 - - | netcat -q0 -l -p 2999 | celtdec - - | aplay -f dat
                
                

                sachant que -f dat correspond à --format S16_LE --rate 48000 --channels 2

                Effectivement, quand on compare la première méthode que j'ai présenté et celle ci pour faire du duplex audio en CELT, et la méthode de guillaume et la tienne pour encoder en mp3, y a pas photo, celles qui n'utilisent pas gstreamer sont plus simple.

                Sauf que... dans mon exemple avec netcat
                - je ne sais pas gérer la gigue
                - si un des deux bouts plantes, les deux s'arrêtent
                - si l'un des deux envoie avec de l'avance, c'est autant de retard (accumulé dans le pipe) qui ne sera jamais récupéré
                - etc.

                Dans ton exemple de fichier mp3, clairement, les paramêtres d'ffmpeg sont conçus pour les usages communs quand on garde tout par défaut, donc évidemment ça déchire tout, il va deviner ton format avec l'extension, etc. Si tu veux modifier ces optiond par défaut (cbr ou vbr ? échantillonage ? nombre de canaux ? bitrate ? ta commande ffmpeg ne sera pas beaucoup plus courte que la commande gstreamer. Et avec la commande gstreamer, tu pourras faire plus que ce que tu fais avec ffmpeg. Ton -i il prend un fichier, avec gstreamer tu n'as pas que les fichiers, tu va pouvoir prendre en source un flux réseau (udp, ou avec netcat ;), une archive... Tu pourras toujours piper ton entrée standard avec d'autres outils, mais c'est justement là qu'on approche l'avantage cité par Guillaume : ton pipe gstreamer, il contient des métadonnées sur la nature du flux que tu pipe.

                Là où avec les pipe unix, il faut que tu surcharges toutes tes commabdes du format d'échange

                arecord --format S16_LE --rate 48000 --channels 2 --file-type raw | celtenc --16bit --rate 48000 --stereo --bitrate 256 --framesize 64 --comp 0 - -
                
                

                une fois que tu as précisé le format que tu voulais audio/x-raw-int,rate=48000,width=16,channels=2, tu n'as plus besoin de le repréciser entre chaque pipe, si on voulait ajouter des effets par exemple :

                gst-launch-0.10 -v alsasrc ! audioconvert  audioresample ! "audio/x-raw-int,rate=48000,width=16,channels=2" ! effet1 option-effet1 ! effet2 option-effet2 ! effet3 option-effet3 ! celtenc option-celtenc ! rtpceltpay ! udpsink
                
                

                alors qu'avec des pipe unix tu fais un truc du genre
                arecord --format S16_LE --rate 48000 --channels 2 --file-type raw | effet1 --format S16_LE --rate 48000 --channels 2 --file-type raw --option-effet1 | effet2 --format S16_LE --rate 48000 --channels 2 --file-type raw --option-effet2 | effet3 --format S16_LE --rate 48000 --channels 2 --file-type raw --option-effet3 | celtenc --16bit --rate 48000 --stereo --bitrate 256 --framesize 64 --comp N - - | monPayloadRtpSurUDP --bitrate 256 --framesize 64 --comp N --option-rtp
                
                

                et j'imagine même pas si je veux traiter la vidéo en même temps que le son, sur le même pipe ;) déjà que piper de la vidéo c'est bien plus coton que du son PCM...

                Donc en fait, ffmpeg (et mplayer) c'est bien tant que tu n'as rien à piper, et que tu travailles de fichier standard vers fichier standard, avec des options communes, ton exemple d'extraire un mp3 d'un flv.
                Dès que les options ne sont pas celles par défaut, la verbosité devient kifkif, alors dès que les usages commencent à ne plus être "communs", n'en parlons pas :)

                VLC s'approche plus de ce que fait Ggstreamer, mais là je suis d'accord avec toi, c'est inhumain. :D

                ce commentaire est sous licence cc by 4 et précédentes

                • [^] # Re: Pas encore au niveau de VLC

                  Posté par . Évalué à 3.

                  Entendons-nous bien. Je ne dis pas que gstreamer n'a pas son utilité au contraire. Je dis juste que pour des besoins simples voir triviaux ffmpeg est pas mal.

                  Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

                • [^] # Re: Pas encore au niveau de VLC

                  Posté par . Évalué à 4.

                  avec gstreamer tu n'as pas que les fichiers, tu va pouvoir prendre en source un flux réseau (udp, ou avec netcat ;)

                  Là je t'arrête tout de suite. Envoyer et recevoir du son par réseau c'est PulseAudio qui le fait et c'est le seul à savoir le faire (je sais ça fait quelque temps que je ne me suis pas rasé …).

                  Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

  • # Opera, gstreamer et webp

    Posté par . Évalué à 10.

    Puisqu'Opera est cité dans l'incipit de l'annonce, il serait juste de rappeler que le navigateur n'est pas qu'un simple utilisateur :

    It's worth noting that the changes to GStreamer made by Opera needed to support WebM have been contributed to the GStreamer project, helping bring WebM playback to Linux desktop applications.
    in "Opera supports the WebM video format", http://dev.opera.com/articles/view/opera-supports-webm-video/

    Autrement dit, Opera a ajouté le codec webm à GStreamer, et c'est ce qui lui permet de "diffuser des séquences audio‐vidéo en HTML 5 sur GNU/Linux, Mac OS X et Windows". Il faut se réjouir quand un logiciel propriétaire respecte le logiciel libre, et surtout quand il y participe en coopération avec les principaux développeurs.

  • # Nouvelle estimation de la date de sortie : février/mars 2012

    Posté par (page perso) . Évalué à 1.

    initialement prévue pour fin 2011, GStreamer 1.0 sortirait finalement en février ou mars 2012.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.