MPlayer a forké

Posté par  . Modéré par Benoît Sibaud.
Étiquettes :
0
20
mar.
2002
Linux
Un projet MPlayerxp a vu le jour suite à un désaccord sur l'implémentation des threads dans MPlayer entre Nick Kurshev, l'auteur de Vidix et de nombreuses optimisations de MPlayer, et Aki.
Kurshev a pondu un patch de 5KB rendant MPlayer multi-thread comme beaucoup d'autres lecteurs multimédia;Ce patch a été refusé par Aki qui souhaite garder le choix d'un lecteur non threadé.

En visitant le site de MPlayer, on apprend aussi qu'une nouvelle version arrive bientôt.

Aller plus loin

  • # Note du posteur

    Posté par  . Évalué à 10.

    Désolé pour la pauvreté de mon argumentaire sur le fork de mplayer, mais comme je n'ai pas de compétences fortes en prog, je peux pas dire si c'est un avantage ou non pour le gain de performances.
    Perso, je ne suis même pas arrivé à le compiler hier soir ...
    merci de votre indulgence !

    • [^] # Re: Note du posteur

      Posté par  . Évalué à 10.

      le multithread est clairement un gain de performances... je me souviens de XMMS (à l'époque X11AMP) quand il est passé multithread, le gain de performances "apparent" était énorme. Disons que le player n'est pas forcément hyper plus rapide, mais il fonctionne beaucoup mieux en multitache (le noyau linux n'étant pas -encore- préemptable, là aussi ça a son intérêt) le résultat est appréciable: plus de "coupures" dans la lecture des DIVX, fluidité parfaite même si LICQ décide de kikooter à ce moment là... avec x11amp on a même pu tout à coup bouger la fenêtre en écoutant un mp3 ;-)

      et en lisant les liens, je crois que ce n'est pas la seule chose qui motive ce fork en plus. il semble que le type veuille également permettre de changer les librairies liées à mplayer sans avoir forcément besoin de le recompiler, c'est à dire par l'ajout d'une couche d'abstraction, ce qui devrait également avoir pour conséquence de permettre à terme une distribution _binaire_ de MPlayer, ce qui est une très très bonne chose, surtout si l'on considère que le programme doit également pouvoir être utilisé par le plus grand nombre.

      • [^] # Re: Note du posteur

        Posté par  (site web personnel) . Évalué à 10.

        Oui le multithreading est potentiellement une amélioration considérable.
        Mais la programmation efficace en multithread est délicate. C'est donc aussi la porte ouverte à de nombreux bugs et comportements non déterministes...
        La version multithread doit roulaize à terme.

      • [^] # Re: Note du posteur

        Posté par  (site web personnel) . Évalué à 10.

        <<le multithread est clairement un gain de performances...>> C'est quand même beaucoup plus subtil que ça. Le surcoût engendré par le scheduling entre les différents threads fait qu'un logiciel de calcul multi-thread est toujours moins performant qu'un logiciel de calcul mono-thread. Par contre, il se trouve que le hard ware PC est en fait une machine parallèle. Par exemple, on peut envoyer des données à la carte son ou en récupérer sur le disque et faire autre chose en même temps. L'avantage du multi-thread est qu'il permet de profiter (même sur une machine mono-processeur) de ce parallelisme. On peut par exemple programmer des entrées/sorties non bloquantes ce qui améliore notablement les performances des logiciels qui en font. Pour un logiciel de calcul pur et dur, le multi-thread ne sert à rien sur un mono-processeur.

        • [^] # Que vallent les treads sous UNIX?

          Posté par  . Évalué à 10.

          Je suis étonné de voir que de nombreuses applications évitent de plus en plus l'utilsation de threads, car il semble que les threads sous linux ont des limitations. Je me base ici sur une annonce faite sur le site http://proxy.sourceforge.net/,(...) site qui propose un proxy sous linux
          Je cite:

          Proxy is an IP filtering proxy server for Linux written by InnerTek Software. It was written to solve the problem of being able to connect to machines behind a Linux firewall. There are both threaded and non-threaded versions of proxy in the download area. Threads were abandoned in release 2.2.3 while we spent some time figuring out the thread limitations in the Linux threads library.


          Qui peut apporter des explications? Merci d'avance pour toute explication.

          • [^] # Re: Que vallent les treads sous UNIX?

            Posté par  (site web personnel) . Évalué à 10.

            C'est étrange comme remarque (je parle des développeurs de Proxy). Franchement, les threads Linux sont en gros des threads posix gérés par le noyau, donc je ne vois pas trop. Il y a bien un truc compliqué au sujet de la gestion des signaux, point sur lequel les threads linux ne respectent pas le standard posix.

            La seule idée qui me vient concerne le modèle d'implantation des threads linux : c'est un modèle one-to-one, c'est à dire qu'un thread applicatif correspond à un thread noyau. Ca veut dire qu'avoir 1000 threads dans une application sous linux, ça risque de ramer à mort. Mais il faut être crétin pour avoir 1000 threads dans une application. Ceci étant, certaines implantations des threads sont basées sur des modèles très compliqués many-to-many (cf http://pauillac.inria.fr/~xleroy/linuxthreads/faq.html(...)) qui correspondent en gros à avoir un double ordonnancement, à la fois au niveau utilisateur et au niveau noyau : en gros, un groupe de thread de l'application est représenté par un thread noyau. Ca permet de faire des applications de bourrin, genre 1000 threads, justement.

            Le problème, c'est que beaucoup de développeurs pensent que threads => performances, et on arrive à des trucs débiles (toujours les 1000 threads).

      • [^] # Re: Note du posteur

        Posté par  (site web personnel) . Évalué à 5.

        Tout d'abord, je suis d'accord avec boubou. Les threads permmettent de séparer les activités d'un programme dans différentes unités d'exécution. Cela permet donc de meilleures performances si l'on a un programme avec des appels bloquants indépendants les uns des autres, mais sinon, c'est plutôt le contraire.

        Ensuite, j'aimerais savoir ce que cela change dans le cas où un autre programme vient afficher une fenêtre (l'exemple de Licq). Personnellement, je ne vois pas de différence entre mono thread et multi thread dans ce cas. Quelqu'un pourrait confirmer/infirmer, avec des explications ?

        • [^] # threads vs select()

          Posté par  . Évalué à 7.

          La plupart des toolkits sont bâtis autour d'un select, qui permet à la fois de multiplexer les I/O, qu'elles soient bloquantes ou non (ça se paramètre), les signaux Unix et les timer. À partir de là on peut tout à fait se passer des threads. (voir par exemple gmain.c dans la glib de gtk, ou encore dans le source de mon toolkit http://www.lim.univ-mrs.fr/~thiel/helium/gui/io.c(...))

          De ce point de vue il n'y a aucune raison de croire qu'un prog multi-threadé serait plus performant qu'un prog non multi-threadé autour d'un select.

          Le seul intéret du multithread est lors de calculs intensifs : on peut loger ces calculs dans un thread, tandis qu'un autre gère le GUI par exemple, qui n'est donc pas bloqué pendant le calcul.

          On peut toutefois bricoler en logeant des tours de boucle d'évènement au milieu du calcul (gtk permet de faire ça) mais c'est lourd et chiant à gérer.

          Je suis d'accord que l'écriture d'un prog avec des threads est délicate because tous les mutex à placer aux bons endroits. Là aussi on peut regarder le code de la glib dans gtk, chauffe Marcel.

    • [^] # Le fork: enfin libre?

      Posté par  . Évalué à 10.

      Notons que MPlayer n'est pas un logiciel libre:on ne peut pas distribuer librement de binaires. Ca a chauffe chez les distributions. (http://lists.debian.org/debian-devel/2001/debian-devel-200111/msg00(...))

      Ici, le fork aura peut-etre l'avantage d'etre libre pour de vrai? Enfin presque: tant que les divx necessitent les codecs non libres de windows, les lecteurs multimedias compatibles divx ne seront pas a la fois 100% libres et 100% fonctionnels.

      Le bonjour chez vous,
      Yves

      • [^] # Re: Le fork: enfin libre?

        Posté par  . Évalué à 10.

        pour les divx, un gros travail est en cours avec xvid: http://www.videocoding.de/(...)

        après on aura résolu le problème de ce côté là...

        reste le gros problème des DVD avec DeCSS, qui est libre, mais illégal aux US (salauds !)

        • [^] # Re: Le fork: enfin libre?

          Posté par  . Évalué à 1.

          reste le gros problème des DVD avec DeCSS, qui est libre, mais illégal aux US (salauds !)

          Mplayer n'utilise pas DeCSS par défault.

          Sur le site de Mplayers, ils recommandent la libdvdcss du videolan project qui est libre et utilise la licence GPL.

          cette librairie doit être installée avec la libdvdread, également sous license GPL.

          Rassurez moi, là j'ai un doute affreux... elles ne sont pas illégales ces librairies aux USA ?

          • [^] # Re: Le fork: enfin libre?

            Posté par  (site web personnel) . Évalué à 2.

            arf si je ne me trompe pas la libdvdread elle ne peut lire des dvd encryptes que si la libdvdccs ou la libcss sont presente.

            de toute facons aux US toutes les implementations de decryteurs css sont interdites

      • [^] # Re: Le fork: enfin libre?

        Posté par  . Évalué à 10.

        Il existe une lib, la libffmpeg, qui est libre et qui permet de lire le divx3, divx4, opendivx, msmpeg4, ...

        Elle ne passe malheureusement pas parfaitement sur 100% des vidéos, mais par contre les performances sont bien supérieurs à celles des codecs officielles, d'apès mes tests personnels en tout cas.

      • [^] # Re: Le fork: enfin libre?

        Posté par  . Évalué à 10.

        Notons que MPlayer n'est pas un logiciel libre:on ne peut pas distribuer librement de binaires. Ca a chauffe chez les distributions.
        La raison exacte est que le source contient des fichiers ayant des licences incompatibles. Sous forme de sources, elles sont legalement assemblees, mais pas la redistribution de la version binaire ne l'est pas. Ils sont en train de changer le code non-GPL en code GPL a terme.
        De plus ils recommandent la compilation "a la main", car MPlayer est tres dependant des optimisations CPU, et que les routines de detection sont faciles avec un ./configure mais greveraient les performances si l'executable binaire avait cette charge.

        • [^] # Re: Le fork: enfin libre?

          Posté par  . Évalué à 10.

          source contient des fichiers ayant des licences incompatibles

          Alors c'est pas un logiciel libre. C'est pas une critique ni un troll, c'est un constat.

          ils recommandent la compilation "a la main", car MPlayer est tres dependant des optimisations CPU

          Ca, c'est si tu veux un lecteur plus performant.
          Mais si le lecteur ne tournait pas sans ces optimisations, alors il serait bon pour la poubelle puisque d'autres (xine, ogle...) le font.

          Ensuite, c'est le role des distributions de
          - faire des packages en fonction des utilisateurs cibles (redhat x86 vise tous les x86 alors que mandrake x86 ne vise que les 586 et superieurs par exemple)
          - faire des packages des logiciels. A toi de recompiler le soft avec tes optimisations si tu le veux et si t'en es capable. L'utilisateur lambda, s'il n'en est pas capable, il sera content d'avoir son package: il n'aurait pas utilise le soft sinon.

          Apres, si les distributions veulent faire les choses bien, ils font N packages du meme soft, un par type de machine.

          En bref, recommander la compilation "a la main", oui, c'est bien. Utiliser cela comme une raison (j'ai pas dit LA raison) pour interdire la distribution de binaires, NON.

          Le bonjour chez vous,
          Yves

          • [^] # Re: Le fork: enfin libre?

            Posté par  . Évalué à 3.

            >>source contient des fichiers ayant des licences incompatibles

            >Alors c'est pas un logiciel libre. C'est pas une critique ni un troll, c'est un constat.

            Si la seule chose exigée est que la distribution soit faite sous forme de sources et pas de binaires, il y a des chances que çà rentre encore dans la définition de logiciel libre, aussi bien FSF qu'OpenSource.

            Évidemment, c'est pénible, mais l'utilisation, la modification, la redistribution etc. sont possibles (mais sous forme source). C'est un cas (assez rare finalement) de logiciel libre avec une licence très restrictive par rapport aux licences habituelles.

            Amha c'est bien libre, mais c'est typiquement le genre de particularité qui serait « fortement déconseillée » en annexe des définitions du libre (que ce soit FSF, OpenSource, DFSG...)

            • [^] # Re: Le fork: enfin libre?

              Posté par  . Évalué à 1.

              « Si la seule chose exigée est que la distribution soit faite sous forme de sources et pas de binaires, il y a des chances que çà rentre encore dans la définition de logiciel libre, aussi bien FSF qu'OpenSource. »

              Pas évident du tout. Un logiciel est un tout.

              Et si une partie, rien qu'un fichier, n'est pas libre, le logiciel n'est pas *vraiment* libre.

              • [^] # Re: Le fork: enfin libre?

                Posté par  . Évalué à 2.

                Pas évident du tout. Un logiciel est un tout.

                Et si une partie, rien qu'un fichier, n'est pas libre, le logiciel n'est pas *vraiment* libre.

                Pour ça, je suis tout à fait d'accord. Le moindre élément non libre d'un ensemble rend cet ensemble non libre (d'où les trolls sans fin sur SuSE).

                Mais ici, si j'ai bien compris, tous les fichiers sont libres. Ils ont cependant une restriction peu fréquente, qui est que la distribution doit etre faite sous forme source, et non sous forme binaire. C'est une exigence technique de distribution qui n'entrave aucune des 4 libertés.

                C'est un peu comme l'interdiction de modifier les sources autrement que par patches séparés (distribuer un travail dérivé sous forme source originale + patch). C'est une restriction importante, mais les 4 libertés sont respectées, et ce type de restriction est toléré par la FSF comme par l'OSI (c'est explicite sur les sites) bien que ce soit en même temps fortement déconseillé.

                Amha, exiger la distribution sous forme source est une restriction du meme type. (mais il y a peut-etre d'autres restrictions que j'ai oubliées? je ne parle que de cette exigence).

                C'est pas que je souhaite absolument placer ce logiciel dans la catégorie 'logiciel libre', je trouve aussi que la restriction est excessive, et assez pénible. Conseiller de recompiler soi-meme serait largement suffisant, et les distribs peuvent faire de très nombreux packages avec telles et telles optimisations... Mais ça me parait simplement respecter les 4 libertés, intégralement, meme si on est habitué à des licences plus souples.

        • [^] # Re: Le fork: enfin libre?

          Posté par  (site web personnel) . Évalué à 10.

          La raison exacte est que le source contient des fichiers ayant des licences incompatibles

          Et pleins de fichiers sans licence affichée, ce qui a l'air de poser contestation pour le fork justement


          Sous forme de sources, elles sont legalement assemblees, mais pas la redistribution de la version binaire ne l'est pas

          C'est leur version, et c'est tres contestable (et contesté sur la ML d'ailleurs). Leur argument c'est que mplayer n'est pas un programme mais une collection de sources. Donc les clauses "contaminantes" de GPL s'applicant aux programes ne s'apliquent pas là.

          Perso je ne suis pas convaincu, une collection de sources prévues et rassembler en un endroit, avec d'autres sources pour pouvoir tout compiler ensemble (meme s'il n'y avait que un makefile, mais là il y a tout un "programme" en code source liant le tout), le tout avec de plus un nom, des screenshots et tout le tatoin peut bien etre considéré comme un programme. Surtout que c'est destiné à la compilation. Meme si c'est légal (à mon avis ca ne l'est pas) c'est très limite comme raisonnement, et permettrait alors la redistribution de code GPL mélé à du code non libre (par exemple non librement redistribuable) sous forme de code source (sous entendu la GPL serait compatible avec n'importe quoi, meme du non libre, tant qu'on ne distribue que les sources).

          De plus ils recommandent la compilation "a la main"
          Mouais ca c'est aussi pour justifier à postériori le fait de ne pas pouvoir donner de binaire. Car proposer un binaire n'a jamais empecher quelqu'un de compiler les sources disponnible à coté s'il le veut.

      • [^] # Re: Le fork: enfin libre?

        Posté par  . Évalué à 10.

        Notons que MPlayer n'est pas un logiciel libre:on ne peut pas distribuer librement de binaires. Ca a chauffe chez les distributions. (lists.debian.org/debian-devel/2001/debia)
        Disons que la distribution binaires de MPlayer se heurte a quelques problemes juridiques:

        http://www.mplayerhq.hu/DOCS/users_against_developers.html#binary(...)

        Mais la volonte des auteurs est quand meme de retrouver le droit chemin de la GPL pour les prochaines versions.

        Ici, le fork aura peut-etre l'avantage d'etre libre pour de vrai? Enfin presque: tant que les divx necessitent les codecs non libres de windows, les lecteurs multimedias compatibles divx ne seront pas a la fois 100% libres et 100% fonctionnels.

        La c'est un point qui n'est plus vraiment valable, en utilisant les codec de ffmpeg ( http://ffmpeg.sourceforge.net/#formats(...) ), on peut quasiment rester GPL au niveau des codecs. En plus la rumeur veut que la libavcodec de ffmpeg soit plus rapide/moins gourmande/moins x86 que l'utilisation des ddls windows.. alors pourquoi se priver ?

        • [^] # Re: Le fork: enfin libre?

          Posté par  . Évalué à 3.

          En plus la rumeur veut que la libavcodec de ffmpeg soit plus rapide/moins gourmande/moins x86 que l'utilisation des ddls windows.. alors pourquoi se priver ?

          et du divx4 natif ? , parce que maintenant il n est plus indispensable de passer par les dll windows.
          http://www.divx.com(...)

          • [^] # Re: Le fork: enfin libre?

            Posté par  . Évalué à 10.

            j'ai peur que l'on sorte du debat:


            On reste donc dans le debat : "Comment faire pour pouvoir sortir des binaires de mplayer"

            • [^] # Re: Le fork: enfin libre?

              Posté par  (site web personnel) . Évalué à 7.

              Le meilleur Codec DivX pour Linux, aussi bien pour encoder que pour décoder, c'est XviD et il est d'ailleurs supporté dans MPlayer :

              http://www.videocoding.de/(...)

              C'est de l'open source mais c'est un mélange entre la OpenDivX license et la license GPL pour les évolutions (c'est expliqué sur leur home page).

              D'ailleurs, MPlayer n'est pas qu'un excellent player, ça commence aussi à être un encodeur intéressant avec mencoder (qui se compile et s'insalle en même temps que mplayer).

              Mais bon, pour l'instant, pour ce usage, je préfère encore transcode :
              http://www.theorie.physik.uni-goettingen.de/~ostreich/transcode/(...)

              • [^] # Re: Le fork: enfin libre?

                Posté par  . Évalué à 3.

                Je commence a avoir un peu d'experience avec les encodages ;) et oui le Xvid est excellent, bien meilleur que le 4.12. Il a maintenant le post-processing qui lui manquait depuis longtemps.
                Mais depuis le DivX5 montre sa superiorite (mais c'est vrai, pas dans toutes les conditions) grace a l'apport des B-Frames (un nouveau type d'intra-frame qui tient compte de la precedente et de l'interframe suivante) qui ameliorent la qualite pour la meme taille. Ces B-frames vont etre introduits prochainement dans le codec Xvid et comme ce codec a toujours ete superieur a celui de DivXNetworks, on peut esperer qu'il en sera de meme.
                De plus, le divX5 ne marche pour l'instant que sous Windows, ou il installe un spyware (gator) pour payer les royalties mpeg4. Le moyen de desactiver le spyware est publie sur http://www.doom9.net(...) et son forum http://forum.doom9.net(...)

                • [^] # Re: Le fork: enfin libre?

                  Posté par  . Évalué à 2.

                  De plus, le divX5 ne marche pour l'instant que sous Windows

                  bof:
                  mplayer : cvs d'aujourd'hui
                  ffmpeg : cvs d'aujourd'hui
                  .avi : recuperer sur http://www.divx.com/showcase/(...)

                  ligne de commande:
                  mplayer -vfm 5 xXx_DivX.avi

                  resultat:
                  [...]
                  Trying to force video codec driver family 5 ...
                  Opening Video Decoder: [ffmpeg] FFmpeg's libavcodec codec family
                  [...]
                  Start playing...
                  This file was encoded with DivX500 Build410
                  hmm, i havnt seen that version of divx yet, lets assume they fixed these bugs ..
                  [...]

                  Bin oui c'est joli de Divx5 sous linux avec un codec GPL ;-)

                  Tus

        • [^] # Re: Le fork: enfin libre?

          Posté par  (site web personnel) . Évalué à 2.

          J'apporte mon grain de sel : j'ai personnellement recompilé mon MPlayer (0.60) en enlevant les horribles bibliothèques OpenDivX avec leur licence moisie. Comme le code y faisait référence, j'ai collé à la place deux fichiers .h contenant des stubs (deux fonctions) et quelques #define (une vingtaine de lignes au total. Je ne pense pas être en violation de leur licence)... Le player s'est compilé correctement (j'ai pas essayé l'encoder puisqu'il paraît qu'elles sont nécessaires pour celui-ci) et dans le fichier de configuration des codecs, j'ai mis les codecs FFMPEG par défaut et éliminé par sécurité les lignes se rapportant à ceux non-libres. Eh ben, j'arrive à lire mes vidéos DivX 3/4 sans vrai problème. Et je suis sûr que ma version de MPlayer est GPL ! Je précise bien sûr que je n'utilise pas les codecs Win32 non plus (Linus me garde !). Bref, Arpad Gereoffy fait beaucoup de bruit pour rien. Il ferait mieux d'apprendre à ne pas coder comme un goret (le code de MPlayer est absolument putride, illisible) !

          Ah oui, et au fait, les gusses de videocoding.de (le projet XviD) ont repris le code du Project Mayo, seules leurs modifs sont sous GPL. Autrement dit, ce n'est pas libre. Bref, encore un projet qui ne va pas dans la bonne voie...

          Envoyé depuis mon PDP 11/70

          • [^] # Re: Le fork: enfin libre?

            Posté par  . Évalué à 2.

            J'ai eu quelques echanges de mails avec des developpeurs de Xvid sur le forum de doom9 et ils disaient que les parties non-GPL etaient en cours de reecriture, voire meme deja completement reecrites. C'etait le probleme du filtre de post-processing de Nic par exemple.
            J'essaierai d'en savoir plus la-dessus.

  • # Mauvais lien

    Posté par  (site web personnel) . Évalué à 5.

    Pardon j'ai un problème pour changer le deuxième lien. Le bon est http://www.mplayerhq.hu/homepage/(...)

  • # en esperant que ca va ameliorer les choses...

    Posté par  . Évalué à 9.

    Mplayer est un excellent lecteur, mais j'ai un pc vieillissant, et il est au moins 3 fois plus gourmand en ressources que les autres lecteurs (xine et aviplay).

    j'espère que ce fork va améliorer les choses...

    allez hop, apres une petite compilo (si ca marche !) on sera fixé.

    • [^] # Commentaire supprimé

      Posté par  . Évalué à 3.

      Ce commentaire a été supprimé par l’équipe de modération.

      • [^] # Re: en esperant que ca va ameliorer les choses...

        Posté par  . Évalué à 5.

        j'ai fait mon (très) petit bench, sur une grosse vidéo en mpeg2 :

        50% de cpu sur mplayer
        60% de cpu sur mplayerxp, tout en affichant des **** INTERNAL FATAL ERROR ****** de partout.

        acceleration xvideo, cpu VIA Samuel 2 @ 650 Mhz

        bref, pas encore convaincu...
        bon, c'est une version alpha de chez alpha, comme le montre le numéro de version (0.0.0)

      • [^] # Re: en esperant que ca va ameliorer les choses...

        Posté par  (site web personnel) . Évalué à 2.

        Sur mon coucou (k6-200), cetain divx passe très mal (trop lent). J'ai reparqué que si je vire le son, ca va tout de suite beaucoup mieux. Bref le décodage-diffusion du son est trés gourmand.
        Faudrait peut-être que je passe de oss a alsa non ?

  • # Commentaire supprimé

    Posté par  . Évalué à 3.

    Ce commentaire a été supprimé par l’équipe de modération.

    • [^] # Re: Pq pas faire une option à la compilation ?

      Posté par  (site web personnel) . Évalué à 10.

      C'etait ce qui avait été commencé, mais le mainteneur a viré tout ca.

      l'option était -xp (avec on avait un mplayer en thread, sans un mplayer avec l'ancien noyeau)

      Il y a aussi un beau troll sur les licences dans la ML suite à ca. Celui qui fait le fork voulant mettre en GPL et le code de mplayer étant assez flou sur les licences (pas sur que ca soit trs légal actuellement mplayer, leurs arguments me paraissent légés)

  • # dommage

    Posté par  . Évalué à 10.

    qu'il y ait fork soit, c'est dommage pour le projet mais bon ... non ce qui me chagrinne c'est que le troll apparaisse sur le site de Mplayer expliquant sans preuves que le multi-thread ça pue et que les perfs sont pourris.

    Le site de MplayerXP est plus soft et l'auteur ne crache pas sur son collègue ...

  • # [hs] xp

    Posté par  (site web personnel) . Évalué à 10.

    Est ce qu'il n'y a que moi qui en ait marre de voir du xp partout: drivers, cartes écrans, processeurs, maintenant lecteur?

    Plus personne n'a d'imagination que tout le monde se sent obliger de pomper dans les ressources marketing des autres?

  • # threads

    Posté par  (site web personnel) . Évalué à 10.

    Bon, ça parle de threads, fallait bien que je réponde :D
    Comme on l'a déja dit l'utilisation de threads permet de découper un programmes en unités d'exécution parallèles. Un programme n'est pas plus rapide, (même moins puisqu'il y a + de changements de contexte), mais il sera plus réactif, par exemple le GUI fonctionnera encore pendant le chargement du fichier. Le problème étant bien sur un découpage intelligent (pas si évident que ça à faire), et la synchronisation de tout ça...
    Sous BeOS par exemple, on est obligé d'avoir au moins un thread par fenêtre (en plus du thread principal), donc si une fenetre bloque, le reste fonctionne toujours (si le programme est bien écrit...) (et même on peut débuguer un thread tout en utilisant toujours les autres comme si de rien n'était, par exemple il arrive qu'app_server (l'interface graphique) plante, dans ce cas, le noyau crée un thread supplémentaire chargé de dialoguer avec le débugueur, et un dialogue est affiché, mais les autres threads fonctionnent encore, et tant qu'on ne ferme pas le dialogue ça roule :-)) De même l'explorateur (Tracker) peut planter dans une fenetre, qu'à cela ne tienne, on la met de côté et on continue.
    C'est une force, mais aussi une faiblesse, car ça complique fortement le portage d'application non-multithread (venant d'UNIX), car cela impose de sérialiser les actions des threads de gestion des fenetres.

    Le principal problème à mon avis des threads sous Linux est le même que sous UNIX: l'API
    j'ai déja vu du code pthread... c'est affreux.
    Par comparaison BeOS est enfantin à programmer (encore faut-il savoir ce qu'on fait) (et non à ce niveau là c'est du C pur, puisque ça touche au noyau).

    Pour ce qui est des avantages au niveau multimédia, il est clair que c'est intéressant sur les points suivants:
    - avec une bécane SMP (qq1 m'en offre une à Pâques ?), autrement on a 100% d'un CPU, les autres ne font rien, et la vidéo est sacadée, mais on peut rien faire, puisque c'est monolithique,
    - au niveau de l'architecture, il est plus élégant et plus logique d'avoir un thread de décodage video, un décodage audio, un extraction fichier... ça évite d'avoir une construction du type boucle d'évènement, d'utiliser des trucs du genre select() ou poll()... par exemple pendant que l'extracteur de fichier attend un secteur du disque, on peutfaire du décodage... Egalement ça permet d'assigner des priorités différentes à chaque thread, par exemple on dit que l'audio est + important que la video (on peut dropper une frame sans que ça se voit si cpuload>100%, mais avoir une cassure dans le son c + génant), alors qu'avec un truc monolithique, si on veut pas de glitch -> prio élevée, mais vu que le décodage vidéo prend énormément de ressources et qu'on l'a mis aussi en prio élevée -> le GUI ne répond plus.

    ffmpeg: c'est clair que c'est plus rapide que les codecs en DLL... et le développement des codecs (qui ne sont pourtant qu'une partie de ffmpeg) avance à grand pas... la mailing liste est en ce moment à + de 5 message par jour (y a que 3 ou 4 qui contribuent bcp, le reste étant occasionnel).
    Je rappelle également que ffmpeg justement c'est _aussi_ un convertisseur de fichiers ((open)divx, mpeg1, 2, ...ASF (mais pas WMA), .rm ...) Le seul reproche c'est qu'il encode pas encore en mp3 (juste mp2, et encore y a un patch pour utiliser lame), et qu'il manque aussi le support ogg.

  • # canne you spique frène-tcheu ?

    Posté par  . Évalué à 1.

    Ore explègne ze ingliche termes, plize.

    Un peu d'explication des termes serait bienvenue !
    Car tout le monde ne sais pas ce que signifie "multi-thread" ou "threadé" ou "forké"
    (quoiqu'on devine le sens de fork dès le debut de la news)

    Dans les commentaires, c'est pas beaucoup plus clair :
    ...Le surcoût engendré par le scheduling entre les différents threads ...

    Alors pitié pour les non-initiés, on veut pas être exclus ! (surtout que c'est une news première page)

    • [^] # Re: canne you spique frène-tcheu ?

      Posté par  (site web personnel) . Évalué à 4.

      fork() : appelle système qui dédouble un processus (en crée une copie conforme) C'est le summum de l'élégance, une fonction appellée une fois qui retourne 2 fois :-) (une fois avec un code 0 pour le fils, et l'autre fois dans la père avec le pid du fils comme code de retour)

      thread = processus léger = processus qui partage son espace d'adressage anec un autre, ainsi que le contexte (descripteurs de fichiers...) (les processus, au moins sous UNIX sont normalement chacun dans un espace d'adressage virtuel différent) Il y a 2 façons de gérer des threads, la façon Linux (1-to-1), on prend un PID par thread, et on le gèrenet comme des processus (sauf que certaines parties du contexte sont communes) et le n-to-1 (type BSD) ou l'ordonancement des threads est fait en mode utilisateur à l'interieur même d'un processus.

      pthread = lib standard (POSIX) pour utiliser des threads

      multithreadé = programme créant plusieurs threads pour faire des choses en même temps.

      • [^] # Re: canne you spique frène-tcheu ?

        Posté par  . Évalué à 1.

        et je complete :



        Scheduling : Partage du temps processeur entre les processus par le noyau. En effet, on dit linux multi-tâche, mais ce n'est qu'une illusion : un processeur ne peut effectuer qu'une opération à la fois. Donc, l'un des rôle clef du noyau est de "distribuer" le temps processeur. Comme les pains au chocolats à la récré. Enfin, pour ceux qui ont de la chance :)

        • [^] # Re: canne you spique frène-tcheu ?

          Posté par  . Évalué à -1.

          En fait, vous n'avez pas vraiment compris la question.

          Il me semble que le but de l'excercice n'était pas d'expliquer en détail chaque terme.
          Il me semble qu'il vous était tout simplement demandé d'employer les termes français.

          Quand on vous demande de traduire email, on ne vous demande pas une définition générale du courrier électronique. On vous demande tout simplement de dire "courriel" ou courrier électronique. Ce qui, dans la plupart des cas, évite d'avoir à détailler le sens du mot.

          • [^] # Re: canne you spique frène-tcheu ?

            Posté par  (site web personnel) . Évalué à 0.

            ah, ben oui mais bon... désolé de dénoter, mais multi-thread c'est le terme consacré.
            Effectivement le terme fork peut préter à confusion, vu qu'il est employé ici dans 2 sens différent (appel système et dédoublement du projet).
            pour "threadé" on pourrait dire "fortement parallèle", ou "utilisant des processus légers" ou encore "parallélisée" (mais ça n'a pas tout à fait le même sens, ça ne dit pas si c'est tout sur le même CPU ou pas)

          • [^] # Re: canne you spique frène-tcheu ?

            Posté par  . Évalué à 2.

            En fait, vous n'avez pas vraiment compris la question.

            Si, si, ils ont compris, je demandais une explication des termes.

            Quand à employer les termes francais, c'est pas toujours la panacée, mieux vaut un terme anglais que l'on ne connais pas (et donc on cherche à savoir) qu'un terme mal traduit qui induit en erreur.

            Merci à tous...

        • [^] # Re: canne you spique frène-tcheu ?

          Posté par  (site web personnel) . Évalué à 3.

          Définition complètement fausse. Le partage du temps, c'est le partage du temps, point à la ligne. Le scheduling, c'est l'ordonnancement, c'est-à-dire l'algorithme qui décide dans quel ordre les processus actifs vont être exécutés par le processeur. De plus, une machine mono-processeur actuelle est effectivement multi-tâches, car les entrées-sorties, les calculs, l'affichage, le son, etc. sont chacun géré par des composants différents qui peuvent être actifs en même temps.

Suivre le flux des commentaires

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