Journal encoder sur du multicoeur

Posté par  (site web personnel) .
Étiquettes : aucune
0
20
oct.
2007
Bonjour journal,

Si on achète un ordinateur maintenant, on a le droit entre 2 coeurs ou plus. Cela signifie que l'on souhaiterait utiliser ces 2 coeurs de manières sympatiques et qu'ils soient utiliser. Au mieux que tout aille 2 fois plus vite.

Pour l'encodage par exemple, quand on encode une vidéo, on est un peu navré de voir qu'un seul processeur bosse.

De ma vision d'utilisateurfinaletsurtoutpasdedeveloppeur, je me demandais en quoi il n'était pas possible de multithreder mencoder par exemple.

Ma petite idée (qui doit être super mauvaise, sinon, nuls doutes que d'autres y auraient pensé avant) :
la vidéo fait 2 gigas.
pourquoi ne pas lancer 2 encodages à la volée 1 ) sur la partie [debut:moitié] puis 2) sur la partie [moitié;fin]

et ensuite, en phase finale de faire un petit raccord.

2e idée :
pour les séries par exemple (ou meme les films que l'on veut conserver chez soi) : il y a sans doutes des passages "noirs" de 1/2 ou 1 seconde.
pourquoi ne pas séparer le films en parties entre les bandes noires et encoder en // les parties. Le mixage se faisant à la fin ?

merci de ton apport technique cher journal

  • # Les IO

    Posté par  . Évalué à 0.

    Dans ton exemple de fichier de 2 Go, ça va morfler à cause des entrées/sorties.
    Lire le premier octet, puis l'octet 1073741824, puis... (bon, c'est du gros à peu près)
    Le disque dur va pleurer...

    • [^] # Re: Les IO

      Posté par  . Évalué à 6.

      Oui, mais non. En encodage, généralement, le goulot d'étranglement, ça reste le processeur (sauf si ta source est de la vidéo en raw stockée sur le disque, la je dis pas)

      • [^] # Re: Les IO

        Posté par  . Évalué à 3.

        Et puis rien n'empêche d'agrandir les caches pour faire un peu moins souffrir le disque dur. Rien que d'augmenter le cache pendant la lecture d'un film sur portable permet d'économiser la batterie.

  • # Heing ?

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

    C'est quoi de cette blague qu'un seul proc bosse ?
    Si t'utilise des codecs ou bibliothéques alacon possible, mais bon à ma connaissance lavc et x264 entre autre (bon le 1° ne gere quasiement aucun codec existant je dois bien l'avouer.) peuvent faire du multithreading ... (ok avec une petite perte sur l'estimation des mouvements, mais chez moi j'avais bien +50% de fps je crois). Pour xvid apparement y a que l'estimation de mouvements qui est threadable et que pour l'estimation de mouvement (mais j'y connais pas grand chose et si ca se trouve c'est en fait le plus gros du boulot donc pas grave si y a "que" ca de géré.).

    Non moi ce que je trouve dommage comme truc qui sert à rien c'est les cartes graphiques ...
    À vue de nez on devrait au moins pouvoir doubler la vitesse d'encodage en les utilisants

    PS:j'utilise le manpage de mencoder comme source d'information, recherchez thread (original non?) pour s'y retrouver.

    • [^] # Re: Heing ?

      Posté par  . Évalué à 9.

      Non moi ce que je trouve dommage comme truc qui sert à rien c'est les cartes graphiques ...
      À vue de nez on devrait au moins pouvoir doubler la vitesse d'encodage en les utilisants
      Sauf que les cartes graphiques ont des accès rapide dans le sens cpu->gpu mais pas dans l'autre sens.

      Sinon, c'est loin d'être trivial pour faire un encodeur multithread surtout si tu veux garder les meme perf en monothread et pas trop perde de qualité en multithread.

    • [^] # Re: Heing ?

      Posté par  . Évalué à 5.

      bon le 1° ne gere quasiement aucun codec existant je dois bien l'avouer.
      Tu veux dire que mpeg4 c'est pas utilisé ?
      Ah première nouvelle.

      • [^] # Re: Heing ?

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

        Tu veux dire que lavc ne fait que du mpeg4 ?

        Ce que t'as cité ca s'appelle de l'ironie.

        • [^] # Re: Heing ?

          Posté par  . Évalué à 2.

          au temps pour moi.
          J'hésitais et j'ai pris le mauvais choix ;)

    • [^] # Re: Heing ?

      Posté par  . Évalué à 2.

      Tout à fait.

      Pour mencoder je pense qu'il faut cependant le compiler pour utiliser plusieurs cpu.

      • [^] # Re: Heing ?

        Posté par  . Évalué à 2.

        non.
        C'est x264 qu'il faut compiler avec le support des threads.

        • [^] # Re: Heing ?

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

          x264 si on parle de x264 et ffmpeg ou mplayer si on parle de lavc... (la plupart du temps mplayer, après ca depend un peu de l'humeur et du packaging, mais ffmpeg est intégré dans mplayer (au sens propre, ie y a un lien vers le svn de ffmpeg sur le svn de mplayer qui récuper les sources utiles de ffmpeg automagiquement))

    • [^] # Re: Heing ?

      Posté par  . Évalué à 6.

      >> j'utilise le manpage de mencoder comme source d'information

      Alors, ça, c'est de la page de manuel!

      Je joue un peu avec mencoder et x264 ces temps-ci, et c'est vraiment tripant... d'autant plus avec une doc aussi abondante.

      Ne pas oublier non plus d'aller jeter un coup d'oeil à la doc html de mplayer, qui fournit pas mal d'informations détaillées sur l'intérêt de certaines options et sur la manière de s'y prendre pour faire les choses proprement (notamment sur le désentrelaçage/dételecinage et sur les spécificités de chaque type de codec)...

      D'ailleurs, autant dans la page de manuel que dans la doc html, il est mentionné que le multithreading a un effet néfaste sur la qualité d'encodage finale (enfin, très peu avec le H.264, déjà beaucoup plus avec le mpeg4 à l'ancienne, type xvid)... après, avec certaines options qui améliorent le rapport signal/bruit de plusieurs ordres, de grandeurs par rapport à la destruction apportée par le multithreading, ça peut facilement devenir négligeable...

      ... bon, par contre, rajouter des options qualitatives plombe la vitesse d'encodage... mais heureusement, on est à l'heure des multi-cores (je dois avouer que je trouve très sexy le Q9450 d'intel qui doit sortir au prochain trimestre... d'autant plus que j'ai une des quelques cartes mères i975 qui passent avec les 45nm), et x264 est très scalable (j'obtiens +90% de vitesse d'encodage entre threads=1 et threads=auto sur mon E6600... raaah... vivement le Q9450)... amis des nuits de calcul bourrines, bonsoir.

      • [^] # Re: Heing ?

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

        tu aurais un exemple de ligne d'encodage pour ça ?

        • [^] # Re: Heing ?

          Posté par  . Évalué à 4.

          Pour ça quoi? Pour obtenir beaucoup d'amélioration de la vitesse? Ou pour obtenir beaucoup d'amélioration de la qualité?

          Pour l'instant, je n'en suis qu'à jouer et à créer mes scripts (niveau gui, sous Debian, il n'y a que dvd:rip, qui se base sur transcode, pas compatible avec le H.264 multi-pass en ce moment et que j'ai le sentiment de moins pouvoir maîtriser que mencoder en shell, mais pas d'acidrip, qui a somme toute l'air bien sympa... en gros, je me crée un frontend en shell pour ripper plusieurs DVD à la suite, et en faire des mkv en H.264/AC3/VOBSub, à partir de fichiers de configuration qui spécifient tout ce dont j'ai besoin)...

          ... je n'ai pas encore fait tous les tests qui me permettent d'affirmer être satisfait de la qualité et j'ai encore des soucis comme l'utilisation vraissemblable d'options non supportées par le décodeur dans mplayer (plein de messages à la lecture), mais il m'a semblé que plus j'utilisais d'options stressant le CPU (sur le E6600 overclocké @3,4GHz, je mets entre 45 et 60 minutes pour un encodage en deux passes H.264 d'un épisode type Simpsons ou Futurama, avec un très gros bitrate ne réduisant finalement la taille du fichier que de moitié... la taille est évidemment une préoccupation, sinon, je n'encoderais pas, mais je voudrais rester le plus proche possible de la qualité originelle du DVD), plus le passage de threads=1 à threads=auto était bénéfique...

          ... je ne certifie donc ni la pertinence, ni l'efficacité pratique de ces réglages (inspirés de la page de manuel, de la doc html et du forum de doom9.org... et que je suis encore en train de tester quand j'ai du temps, plus pour l'amusement que sérieusement pour l'instant)...

          ... j'utilise des profils mencoder, et la dernière fois que j'ai testé, les parties relatives aux options d'encodage étaient quelque chose du genre (désolé si la ligne est un peu longue...):


          [h264hq]
          x264encopts=subq=6:brdo=yes:bime=yes:fast_pskip=no:dct_decimate=no:partitions=all:8x8dct=yes:me=umh:subme=7:trellis=2:frameref=6:mixed_refs:bframes=3:b_pyramid=yes:weight_b=yes:threads=auto:ssim=yes:psnr=yes


          [pass1]
          profile=h264hq
          x264encopts=turbo=1:pass=1


          [pass2]
          profile=h264hq
          x264encopts=turbo=0:pass=2



          ... des estimations sur l'amélioration du PSNR pour chaque option peuvent être trouvées dans la doc html de mencoder, et des discussions sur le même sujet, sur le forum de doom9.org... je n'en dirais pas plus là-dessus, n'ayant guère encore vérifié, quantitativement, la question avec plus de rigueur qu'une loutre bourrée ne l'aurait fait...

          ... pour ce qui est du désentrelacement, ça peut être beaucoup plus compliqué et ça dépend hautement de la video (ça peut être entrelacé, téléciné, hard téléciné, mixé progressif/hard-téléciné)... ça, pour l'instant, j'en suis encore à voir comment gérer la chose... par contre, ça bouffe aussi du proc, quelque chose de mignon...

          • [^] # Re: Heing ?

            Posté par  . Évalué à 2.

            J'ai découvert il y a un peu de temps maintenant ce tutoriel :
            http://linuxdansmonpc.is-a-geek.com/index.php?page=rip_dvd_m(...)

            Je voulais faire une petite interface mais je n'en ai pas eu le temps (et ça ne va pas en s'arrangeant).

            J'avais pensé que le plus simple était de d'adapter Acidrip, mais je n'y suis pas parvenu.
            Au passage, je trouve dommage que cette application ne soit toujours pas « multilangue » (de mémoire les noms sont mis « en dur » dans le programme en Perl.

  • # Re:

    Posté par  . Évalué à 3.

    > je me demandais en quoi il n'était pas possible de multithreder mencoder par exemple.

    Il est possible. C'est quasiment toujours possible.
    Mais de façon général, le multi-threading avec pour abjectif le gain de performance, est l'enfer du développeur.
    Je le sais bien, j'en fais (et dans le domaine de la vidéo). Et franchement, parfois j'en ai hypra hypra marre. Si je peux éviter le multi-threading, je l'évite sans la moindre miliseconde d'hésitation.

    • [^] # Re: Re:

      Posté par  . Évalué à 2.

      pourquoi est-ce l'enfer du développeur ?
      et très naïvement:
      il faudrait des langages spécialisés, des outils particuliers, une manière différente de coder , ... ?

      "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

      • [^] # Re: Re:

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

        mutex, deadlocks, utilisation concurrente etc.

        le multithreading est un développement contraignant.
        Les bugs sont plus "aléatoire" et donc leur reproduction plus difficile ...

        Mais bon là on parallélise un traitement, chose que je n'ai jamais eu l'occastion de faire. L'usage le plus courant est de faire une tâche pour un traitement spécifique ..

        • [^] # Haskell !

          Posté par  . Évalué à 3.

          Ou comment la programmation pure te sauvera des aléas de l'impératif :) (pas d'effet de bord, donc pas de dead lock et autres joyeusetés) :

          http://haskell.org

          (il faut aussi citer erlang, qui est spécialement orienté concurrence, mais que je connais moins.. dans tous les cas, c'est du bon ^_^)
          Bref, pour peu que tu trouves le temps de t'intéresser à ces deux langages fondamentalement différents de ce que tu dois connaître, je pense que tu y trouveras ton compte.

          • [^] # Re: Haskell !

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

            - Pour mon besoin, ca doit compiler partout (linux, aix, solaris, hpux, win32, mvs)
            - Utilisation de bibliothèques propriétaires (je n'ai que des .h en entrée)
            - Un gros passée de 20 ans tout en C.
            - le binaire doit être autonome, le client ne doit rien installé de plus.

      • [^] # Re: Re:

        Posté par  (Mastodon) . Évalué à 8.

        Quand tu programmes dans un langage impératif (comme le C) en mono-thread, tu sais dans quel ordre les instructions seront exécutées. Quand tu programmes en multi-thread, tu ne sais pas si telle instruction du thread 1 sera exécutée avant ou après telle autre du thread 2.

        La solution la plus simple pour ne pas avoir de problèmes, c'est de mettre dans chaque thread des calculs complètement indépendants, de sorte qu'on n'a pas besoin de se préoccuper de leur ordre d'exécution. C'est plus ou moins facile selon le problème à traîter, mais en règle générale c'est très difficile.

        Comme on ne peut pas en général faire ça, on essaye d'avoir des traitements relativement indépendants dans chaque thread, et de "verrouiller" les ressources partagées lorsqu'on les modifie, pour éviter que deux threads se perturbent l'un l'autre. On a différents outils pour ça: verrouiller une variable pour etre sur que personne ne la modifie tant qu'on n'a pas fini, attendre qu'une condition soit vraie, etc. Sécuriser complètement son code ainsi est assez lourd.

        Enfin, une conséquence amusante (ou pas) de l'ordre apparemment "aléatoire" d'exécution des instructions, c'est qu'il est très difficile de reproduire les bugs. Parfois un bug c'est produit parce que telle instruction s'est produite avant telle autre, parce que tel coeur était plus chargé que l'autre à ce moment. Reproduire les mêmes conditions est pour l'instant assez compliqué.

        La solution la plus satisfaisante intellectuellement parlent est d'utiliser un langage fonctionnel, dans lequel on n'a pas d'instuctions qui s'exécutent dans l'ordre, et pas d'effets de bord à l'exécution d'une fonction. Le compilateur est beaucoup plus à même de répartir les calculs entre plusieurs threads dans ce cas.

  • # x264

    Posté par  . Évalué à 8.

    si c'est de l'encodage via x264, celui-ci supporte très bien l'encodage multi-thread. Je recommande particulièrement l'encodage non-déterministe si la vitesse d'encodage est primordiale.

    Sinon, l'encodage de morceaux de fichiers, c-à-d on tronçonne le fichier en bouts de 20 secondes et on soumet les morceaux à plusieurs instances de l'encodeur, ça marche bien. Au boulot on a fait un proof of concept d'encodage vidéo x264 avec un système grid Fura et 22 serveurs avec 2 quad core par serveurs, et ça va très vite...

    • [^] # Re: x264

      Posté par  . Évalué à 6.

      Le problème du tronçonage, c'est que suivant la source à encoder, et le format d'encodage, on peut avoir des informations utiles à l'encodage du morceau avant et après le morceau : trames clés, ou un plan fixe de 60 secondes qui prend 3 fois plus de place s'il est coupé en morceaux d 20 secondes...

      ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

      • [^] # Re: x264

        Posté par  . Évalué à 4.

        Ouais mais dans ce cas ou tu reperes les scenes fixes (pour baisser leur bitrate), c'est justement que tu fais un encodage multipasse.

        C'est donc théoriquement encore tronçonnable (bien qu'il faille se donner plus de peine et pas juste couper le fichier, mais jouer avec le fichiers de stats, etc...)

  • # mp32ogg

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

    Quand j'ai eu mon nouveau laptop bi-core j'ai fait un test de réencodage de morceaux mp3 en ogg/vorbis avec le logiciel mp32ogg.

    Naïvement je m'attendais à un doublement de la vitesse car c'est un cas super facile pour le soft : comme les différents morceaux de musique sont séparés il suffit d'en encoder un avec un core et un autre avec l'autre core. Idéal !

    Malheureusement cela ne s'est pas vérifié et j'ai des temps d'encodage d'un album qui sont tout à fait comparables à ceux de mon ancien laptop monocore (modulo la montée en fréquence du fait du passage à 2 GHz avec le nouveau).

    Déçu je suis :-(

    • [^] # Re: mp32ogg

      Posté par  . Évalué à 5.

      Parce que ce script n'est pas prévu pour... il faudra un jour que quelqu'un s'y penche, pour cela il faut qu'il en ai besoin (cad un machine multicore, et des gros besoins d'encodage).

      En fait le script utilise 2 cores : un pour décompresser, un autre pour compresser. Mais comme la décompression utilise 20 fois moins de calculs, tu ne gagnes que 5% de temps. Il est par contre très facile de lancer le script autant de fois que tu as de coeurs, en mettant les 2 moitiés de l'album dans 2 dossiers différents par exemple. Et là ça ira 2 fois plus vite (à moins qu'un cache matériel commun aux 2 cores ne gâche tout).

      ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

      • [^] # Re: mp32ogg

        Posté par  . Évalué à 4.

        [Il est par contre très facile de lancer le script autant de fois que tu as de coeurs, en mettant les 2 moitiés de l'album dans 2 dossiers différents par exemple. Et là ça ira 2 fois plus vite (à moins qu'un cache matériel commun aux 2 cores ne gâche tout).]

        Il doit aussi être possible d'utiliser GNU Make pour ça et son option magique "-j"

    • [^] # Re: mp32ogg

      Posté par  . Évalué à 5.

      Un petit post où l'on parle de l'encodage multi-core et où l'on peut trouver quelques scripts ou idée de scripts.
      http://linuxfr.org/~Zezinho/24996.html

  • # DVD:RIP

    Posté par  . Évalué à 4.

    ce logiciel fait ce que tu veux, et depuis quelques années en plus. Il a été prévu pour tourner sur plusieurs machines, mais rien ne t'empêche de créer autant d'instances que tu as de cores dans une même machine.

    ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

Suivre le flux des commentaires

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