Journal MPlayer 1.0 RC2 dispo

Posté par  .
Étiquettes : aucune
0
16
oct.
2007
Salut à tous,

C'est curieux qu'il n'y ait pas eu d'annonce, depuis le temps qu'il est dispo, alors voilà: MPlayer 1.0 RC2 est dispo, plus d'un an après la RC1.
L'annonce officielle est ici: http://www.mplayerhq.hu/design7/news.html

Au menu, plein de choses, dont des optimisations PPC/Altivec par votre serviteur ;-)

Pour info, "RC" peut difficilement être compris comme "release candidate" vu qu'aucun effort n'est fait pour geler le code, mais que les bugs sont corrigés au fur à mesure, et les fonctionnalitées sont ajoutées régulièrement.

D'ailleurs, pour ceux qui trouvent que le temps est long entre les releases, utilisez donc le snapshot SVN, il marche (presque) toujours.

  • # À quand la 1.0

    Posté par  . Évalué à 7.

    J'attends avec impatience la version 1.0 qui signifierait qu'elle serait enfin utilisable.

    A bon, ça l'est déjà depuis des années ?

    Bravo en tout cas pour les développeurs, mplayer est vraiment un très bon lecteur, et notons qu'avec smplayer (qui a un développement très actif je crois), on a enfin une interface de qualité à mplayer ce qui lui manquait vraiment.

    • [^] # Re: À quand la 1.0

      Posté par  . Évalué à 3.

      L'interface graphique je m'en fous. Mais je comprend que tout le monde n'aime pas la ligne de commande.

      > mplayer est vraiment un très bon lecteur

      Ce n'est pas qu'un lecteur. Il peut être utilisé pour regarder la tv (v4l, dvb) et pour coder des vidéos. Il fait aussi du processing (crop, redimensionnement, filtrage, désentrelacement, etc).
      Je l'utilise depuis des années et je l'adore. M'enfin, je ne pense pas que mplayer soit pour le linux "pour les masses". Qu'importe, je le kiffe grave.

      • [^] # Re: À quand la 1.0

        Posté par  . Évalué à 1.

        Même avis, mais je vais quand même donner sa chance à smplayer pour une fonctionnalité qui me fait saliver d'avance : le rappel de la position dans la vidéo lors de l'arret/reprise. En plus l'interface est plutot jolie en Qt4 + icones Tango :).

        Faut que je vois pour mater la TNT avec MPlayer aussi. Entre VDR qui ne fait pas de captures d'écran, kaffeine qui les gère mais mal... gnéh c'est quand même basique non ! Bon manquerais l'enregistrement sur pause du coup. Rah, triste vie. ;p

        • [^] # Re: À quand la 1.0

          Posté par  . Évalué à 3.

          > Bon manquerais l'enregistrement sur pause du coup.

          Avec mplayer et pour dvb, je fais très simplement. Certes, il faut taper des lignes de commande, mais ça marche. NB: des scripts simplissimes rendent la chose moins fastidieuse.

          // L'acquisition et enregistrement dans un fichier.
          // Commande à taper dans un terminal.
          // Enregistre dans le fichire tv.dump
          $ mplayer .... -dumpstream -dumpfile tv.dump "dvb://ARTE"

          // la visualisation
          // Commande à taper dans un autre terminal
          $ tail --bytes=`echo 2^40 | bc` -f tv.dump | mplayer ... -

          Le "`echo 2^40 | bc`" est pour avoir un gros nombre.
          Le '-' final indique qu'il faut utilser l'entrée standard.
          Si on a beaucoup de mémoire on peut faire "mplayer -cache 250000 -". Ainsi on peut aussi revenir en arrière de 2 ou 3 minutes. C'est que du bonheur.
          J'ai 512 Mo, j'utilise avec "mplayer -cache 250000".

          • [^] # Re: À quand la 1.0

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

            Et sinon un simple mplayer tv.dump à la place de ta deuxième commande ? Autrement dit ça sert a quoi " tail --bytes=`echo 2^40 | bc` -f tv.dump | " ?

            • [^] # Re: À quand la 1.0

              Posté par  . Évalué à 4.

              Malgré toutes les qualités qu'on peut reconnaître à ce logiciel (et elles sont nombreuses), j'ai tout de même un regret : à l'heure actuelle, la gestion des menus des dvd n'est toujours pas gérée, à moins de patcher le code source.

            • [^] # Re: À quand la 1.0

              Posté par  . Évalué à 2.

              > Autrement dit ça sert a quoi " tail --bytes=`echo 2^40 | bc` -f tv.dump | " ?

              Si tu fais un "mplayer tv.dump", mplayer s'arrête s'il atteind la fin de fichier.
              Avec "tail -f ...", il n'y a pas de fin de fichier. Si tail voit une fin de fichier, il attend (c'est paramétrable avec --sleep-interval) et regarde si des données ont été ajouté à la fin du fichier.

              Avec ce que j'ai donné, on peut "naviger". Si on va au-delà de la fin du fichier, mplayer attend les données (qui seront fournit par tail au fur et à mesure que "mplayer -dumpstream ..." les récupères de la carte dvb (ou autre)).

              • [^] # Re: À quand la 1.0

                Posté par  . Évalué à 1.

                Pas mal, mais du coup on perd en "spontanéité" : impossible de changer de chaine par exemple. Un mplayer dvb:// -cache 250000 directement permet de changer de chaine à nouveau au prix de devoir reconstruire le cache à chaque changement. Et puis on se retrouve vite avec un dump énorme aprés s'être endormi une soirée théma sur Arte (;+p). J'ai pensé a remplacer le tv.dump par un pipe nommé et lancer mencoder en parralèle en cas de besoin mais, je ne sais pas pourquoi, ça me pourri litéralement l'image. :/

                • [^] # Re: À quand la 1.0

                  Posté par  . Évalué à 1.

                  > Pas mal, mais du coup on perd en "spontanéité" : impossible de changer de chaine par exemple.

                  Je vois ce que tu veux. Je ne suis pas un "zappeur" :-)
                  En général j'enregistre (mplayer -dumpstream ... ou avec mencoder comme tu l'indique), puis je regarde. Parfois je regarde avant que l'enregistrement soit terminé (d'où le tail -f).

                  > Et puis on se retrouve vite avec un dump énorme

                  Oui. Mais les disques sont tellement énormes aujourd'hui...

                  > Un mplayer dvb:// -cache 250000 directement permet de changer de chaine

                  Le problème est que dans ce cas, si tu fais pause et que le cache devient plein, l'acquisition est suspendue. Avec ma "solution" ce n'est pas le cas. Je ne perd rien. Et si c'est un bon film, je peux le stocker dans un coin et le regarder une seconde fois (ou le partage avec un pote, de façon tout à fait légale).

          • [^] # Re: À quand la 1.0

            Posté par  . Évalué à 1.

            Merci pour l'idée du tail -f

            Ça marche aussi pour un avi en cours de création _ enregistrement de TV analogique oblige _ sauf qu'on ne peut pas naviguer en arrière.

            Sinon, chez moi, on peut mettre : tail -c+0 -f ...

        • [^] # Re: À quand la 1.0

          Posté par  . Évalué à 2.

          >> Entre VDR qui ne fait pas de captures d'écran [...]

          Salut, vdr gère les captures d'écran.

          help GRAB
          214-GRAB < filename> [ < quality > [ < sizex > < sizey > ] ]
          214- Grab the current frame and save it to the given file. Images can
          214- be stored as JPEG or PNM, depending on the given file name extension.
          214- The quality of the grabbed image can be in the range 0..100, where 100
          214- (the default) means "best" (only applies to JPEG). The size parameters
          214- define the size of the resulting image (default is full screen).
          214- If the file name is just an extension (.jpg, .jpeg or .pnm) the image
          214- data will be sent to the SVDRP connection encoded in base64. The same
          214- happens if '-' (a minus sign) is given as file name, in which case the
          214 image format defaults to JPEG.

          Ceci depuis la console svdrp, il faut penser a mettre le path si tu ne la pas spécifié au lancement de vdr a l'aide du switch:

          -g DIR, --grab=DIR write images from the SVDRP command GRAB into the
          given DIR; DIR must be the full path name of an
          existing directory, without any "..", double '/'
          or symlinks (default: none, same as -g-)

          • [^] # Re: À quand la 1.0

            Posté par  . Évalué à 1.

            Merci, j'étais complètement passé à coté! Il y a un temps de latence important (de 1/2 à 1 sec) mais je ferais avec.

            Merci encore :)

  • # flv

    Posté par  . Évalué à 2.

    À propos de mplayer c'est moi ou y'a un bug de synchronisation AV avec certaines vidéos flv ?

    Sinon excellent player qui lit quasiment tout ! Félicitation aux développeurs !

  • # Optimisations PPC/Altivec

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

    En tant qu'heureux propriétaire d'un iBook G4, ça m'intéresse ! Je suis heureux de voir qu'il y a des courageux pour s'attaquer encore maintenant à une architectures en voie de "moindre utilisation".
    Quelles fonctionnalités sont touchées par ces optimisations et quel est le gain de performances qu'elles apportent par rapport à la 1.0rc1 ?

    • [^] # Re: Optimisations PPC/Altivec

      Posté par  . Évalué à 3.

      C'est surtout le décodage des vidéos H.264 qui a été optimisé, car c'est ce qui en avait le plus besoin (dans le sens où la plupart des G4, si ce n'est pas tous, décodent déjà parfaitement le MPEG4-ASP (XviD)).
      Il y a eu aussi des décodeurs pour format de vidéo moins populaires qui ont été optimisé, mais je sais plus lesquels.

      En tous cas, si tu peux faire un rapide test de performance de décodage H.264, entre RC1 et RC2, je suis curieux de voir les chiffres.
      Sers-toi de la commande:
      mplayer -vo null -nosound -benchmark ma_video.mp4

      • [^] # Re: Optimisations PPC/Altivec

        Posté par  . Évalué à 1.

        et pas d'optimisation du cell
        :'( :'(
        :P

        (pv moi si tu veux un shell sur une ps3, mais le shell sera pas 24/24)
        (perso j'ai pas les connaissances nécessaires pour l'optimisation)

        • [^] # Re: Optimisations PPC/Altivec

          Posté par  . Évalué à 1.

          Le Cell, désolé si je vais choquer certains, mais d'un point de vue architecture, c'est une bouze infâme.
          Les concepteurs du Cell ont cherché à maximaliser le rapport puissance de calcul/transistors, en laissant de côté la programmabilité.
          Ils auraient mieux fait de prendre la direction des multi-coeurs homogènes comme le Xenon de la Xbox360.

          Donc non, je ne suis pas intéressé par écrire des optimisations pour le Cell, sachant que:
          - je n'en profiterais même pas
          - elles sont susceptibles d'être caduques à la prochaine génération du Cell
          - je programme pour des vraies machines, pas des jouets :o)

          • [^] # Re: Optimisations PPC/Altivec

            Posté par  . Évalué à 2.

            bon ben mode "mauvaise foi on" alors :


            ben ca dépend ce que tu veux en faire ensuite c'est tout.
            Pour faire du traitement généraliste voui c'est une bouse infame ... Mais pour faire du calcul scientifique/multimédia, c'est loin d'etre une bouse infame.

            Un peu comme si tu disais qu'un NEC -NSX7 c'était une bouse infame.

            Toute façon folding@home a montré que c'était une bouse infame :P

            Quand au xenon, la gestion du L2 elle se fait si facilement que ça ? (parce que c'est un peu l'une des grands apport du xenon (avec le vmx-128) sinon du multi core on sait faire ... Hein le niagara 2 ? ).

            - je programme pour des vraies machines, pas des jouets
            Les blades de sony dual cell des jouets ? :P
            elles sont susceptibles d'être caduques à la prochaine génération du Cell
            Tu n'est pas forcé d'attaquer les spu en asm. il y a un support en C de mémoire.

            PPs : les multi coeurs sont homogènes, juste que tu confond le PPE , qui n'est pas censé faire du calcul, et les coeurs de calcul sont les SPU.

Suivre le flux des commentaires

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