Journal Quelle est la meilleure méthode pour compresser des fichiers AVI ...

Posté par .
Tags : aucun
0
18
août
2008
... produits par un appareil photo numérique (sous Linux évidement) ?


Une petite recherche Google me donne quelques pistes :

- Avec uniquement transcode (problème on perd le son) :


% transcode -i source.avi -y xvid -N 0x55 -o destination.avi


- Avec mencode (problème on perd en qualité) :


% mencoder source.avi -o destination.avi -ovc lavc -oac mp3lame


- Avec transcode, mplayer, lame, avimerge (un peu lourd mais on conserve la qualité et le son) :


% transcode -i source.avi -y xvid -N 0x55 -o /tmp/video_noSound.avi
% mplayer source.avi -ao pcm:file=/tmp/sound.wav -vc dummy -vo null
% lame /tmp/sound.wav /tmp/sound.mp3
% avimerge -o ./destination.avi -i /tmp/video_noSound.avi -p /tmp/sound.mp3
% rm /tmp/sound.mp3



Mais, y a t il mieux ???
Et surtout quel codec choisir pour un bon rapport qualité/pérennité dans le temps/partage ?
  • # x264

    Posté par . Évalué à 10.

    Pour le moment, le meilleur codec proposé pour la vidéo par l'industrie est le h264, il est de mieux en mieux supporté, y compris par des projets libres comme x264... c'est lent à la compression, mais pour de l'archivage comme pour de la diffusion, c'est très efficace, et la qualité n'a rien à voir avec du xvid.
    • [^] # Re: x264

      Posté par . Évalué à 7.

      une vidéo en .ogv = 34mo
      la même vidéo passer avec : ffmpeg -sameq -i ./mavid.ogv mavid.avi = 74mo
      transcoder ensuite en mp4-avc (x264) = 7mo

      la qualité est toujours là...

      ...
      • [^] # Re: x264

        Posté par . Évalué à 2.

        Bien que n'y connaissant pas grand chose en formats de compression (je n'ai pas d'avis à priori sur l'ogv ni le h624), je crois que le rapport de compression n'a aps grand chose à voir avec la notion de qualité entre formats (j'insiste sur le "entre formats").

        Pour moi, chaque format utilise certains algorithmes de compression et de "simplification" de l'image originelle. De même que chaque codec utilise des options de compression par défaut plus ou moins destructeurs.
        Selon ces choix, la performance de compression peut être plus ou moins bonne mais cela ne renseigne pas sur les pertes (même si on pourrait penser qu'un résultat de compression 2x moins volumineux serait moins bon) de qualité.

        En résumé, "vidéo en .ogv = 34mo" ne dit rien sur les algos/options utilisées (même par défaut), pas plus que "fmpeg -sameq -i ./mavid.ogv mavid.avi = 74mo" + "transcoder (...) en mp4-avc = 7mo"... à moins de tenter de reproduire et de se plonger dans la doc.
        Sachant qu'on ne dispose pas de la video originale...

        Donc, si tu pouvais éclairer notre lanterne sur ces deux formats/codec, par avance merci :)
        • [^] # Re: x264

          Posté par . Évalué à 2.

          Plop Quzqo

          Normal que je ne dise rien sur les algos utilisés : pas de maitrise du sujet.
          Me contente de donner un exemple d' une mini mini chaine de traitement vidéo telle que peuvent la rencontrer de nombreux utilisateurs comme moi...

          ps hors sujet : aurais tu une adresse où l' on puisse lire tes BD ? (si je me trompe pas de personne). Une adresses qui permette d' avoir tes strips & BD sur le bureau (un peu comme celle de userfriendly). D' avance, merci.
          • [^] # Re: x264

            Posté par . Évalué à 1.

            Ref. PS : Désolé il ne doit pas s'agir de la bonne personne. Mon sens artiistique se limite à... profiter de celui des autres :)
        • [^] # Re: x264

          Posté par . Évalué à 3.

          Pour avoir une idée de la qualité un peu plus fiable que le visuel, il y a le rapport signal/bruit qui doit pouvoir être obtenu au moment de la compression. Un rapide tour dans les pages man de mplayer (-lavcopts) me le trouve sous le nom de psnr (peak signal to noise ratio) avec le snr stocké pour chaque image.

          Les autres encodeurs doivent avoir l’équivalent. Ensuite il n’y a plus qu’à faire les tests (en regardant la distribution du snr de toutes les images, car le peak n’est que le maximum et ne renseigne pas sur la moyenne ou l’écart type par exemple).
          • [^] # Re: x264

            Posté par . Évalué à 4.

            le snr peut donner une indiquation mais est loin d'être fiable.
            Si il y a le ssim qui est donné (de tête il est possible de l'avoir avec x264), il faut le préferer au psnr.
            Et si il y a le vqm, la c'est bizance;)
    • [^] # Re: x264

      Posté par . Évalué à 4.

      x264 est génial.
      Mais, il bouffe aussi pas mal de cpu pour décoder.
      Le codage (qualité et débit) dépend des options. Il y a même un mode sans perte (qui bouffe beaucoup de bande passante).

      Je n'utilise plus que ça.
      • [^] # Re: x264

        Posté par . Évalué à 2.

        Là, je suis vraiment étonné. En effet, les algorithme de compression avec et sans perte doivent être bien différent et il me semble étrange de voir les deux sous le même codec. Il me semble que x264 suit une norme (MPEG4-AVC) et n'y collerait sans doute plus avec le mode sans perte.
        Quelqu'un peut-il apporté des éclairssicements ? ai-je mal faux sur un point ?
        • [^] # Re: x264

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

          Il me semble que c'est plus simple que ça en a l'air : si je ne dis pas de bêtises, pour avoir du lossless avec H.264 (ou même MPEG-4 ASF), il suffit d'encoder en spécifiant un bitrate gigantesque. L'encodeur prendra alors autant de place qu'il lui faut pour conserver un résultat identique.

          Evidemment, ce ne sera probablement pas optimal (parce que H.264 n'est pas prévu pour ça), mais c'est mieux que rien.
          • [^] # Re: x264

            Posté par . Évalué à 4.

            Pour le lossless en H.264, l'encodeur prend un gros bitrate, fait la différence entre l'image après compression et la source et compresse le résultat dernière avec un algo lossless de sorte qu'il est possible de reconstituer EXACTEMENT la source au pixel près.

            C'est ce qui est le plus proche de l'optimal, h.264 est prévu pour ça, c'est dans la norme.

            La majorité des compressions audio/vidéo lossless est basée sur cette méthode.
      • [^] # Re: x264

        Posté par . Évalué à 3.

        Ca bouffe sensiblement plus au décodage, mais il faut relativiser...

        Plus ça va, plus les résolutions auxquelles on affiche vont aller vers le 1080p (au moins)... et on n'est pas près d'avoir du progressif pour la plupart des broadcast, ce qui fait qu'il faut aussi désentrelacer...

        Sur ma TV Full-HD, scaler un MPEG II sans désentrelacer bouffe dans les 10% d'un core de mon E4500... un petit coup de yadif 2x pour désentrelacer et que ça ait une bonne gueule, et paf : 60-75% d'un des cores...

        A côté, scaler un H.264 en 576p, ça me bouffe entre 20 et 30% d'un des cores... et pas besoin de désentrelacer...

        Pour ce qui est de scaler du 720p ou d'afficher du 1080p, là, il faut commencer à utiliser les deux cores pour du H.264 (et pas qu'un peu, pour le 1080p... pas encore tombé sur du 1080i qu'il faudrait en plus désentrelacer), certes...

        Mais, au final, si on archive pour regarder sur le PC du salon, principal périphérique du bel écran, de toute façon, le facteur limitant au niveau de la puissance, ça me paraît plus être les résolutions croissantes auxquelles on affiche, et les traitements qui y sont liés, plutôt que le codec en lui-même...
  • # Réponses

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

    Avec mencode (problème on perd en qualité)

    Je ne vois pas en quoi. mencoder dispose d'une véritable pelletée d'options pour choisir les options que tu veux utiliser pour ton codec, et notamment le bitrate, il te permet donc d'atteindre la qualité que tu veux. Je ne vois pas en quoi il serait moins bon que transcode sur ce plan (il est probablement équivalent, peut-être meilleur).

    A te lire on a l'impression qu'avec transcode on ne perd pas en qualité, ce qui est évidemment complètement faux. A partir du moment où ta destination est un format avec perte (lossy), tu as forcément une perte de qualité dans l'opération.

    Et surtout quel codec choisir pour un bon rapport qualité/pérennité dans le temps/partage ?

    D'abord, dans ta phrase tu ne veux sans doute pas parler de codec mais de format. Ce n'est pas la même chose. (et un conteneur c'est encore autre chose)

    Pour l'image, H.264 (MPEG-4 AVC) est ce qui se fait de mieux, mais c'est aussi le plus coûteux à encoder/décoder en termes de temps de calcul. Si tu veux le plus grand dénominateur commun pour le partage, choisis MPEG-4 ASF (dont les principaux codecs sont DivX et XviD).

    Pour le son, selon le format audio original de ta vidéo, il peut être intéressant dans certains cas de le recopier à l'identique (-oac copy). Sinon, choisis FLAC si tu veux du lossless (j'imagine que non), AAC pour le meilleur rapport qualité/poids et MP3 pour le plus grand dénominateur commun.

    Enfin, pour le containeur, Matroska est le meilleur choix surtout si tu veux utiliser H.264 ou AAC. Sinon, le plus grand dénominateur commun est évidemment AVI.

    Concernant la pérennité dans le temps de tous ces formats et conteneurs, je n'en sais fichtrement rien. C'est difficile à dire.

    Au bout du compte, le choix des formats et du conteneur repose en grande partie sur l'utilisation qui va être faite du flux obtenu, et dans quel contexte. Tu n'en dis pas assez dans ton message pour que je puisse t'aiguiller plus.
    • [^] # Re: Réponses

      Posté par . Évalué à 5.

      > Je ne vois pas en quoi il serait moins bon que transcode sur ce plan

      D'autant que mencoder dispose souvent de quelques coudées d'avance sur transcode, en matière de fonctions supportées...

      ... par exemple, la dernière fois que j'avais essayé transcode (ça remonte quand même), il ne supportait pas le H.264 en 2 passes...



      Sinon, le transcodage est un art... et un art, ça s'apprend... Evidemment, la doc de MPlayer/MEncoder est une référence en la matière, mais on peut quand même déjà commencer par lire les pages de manuel (parce que là, tes exemples, ils sentent le copier-coller aveugle à plein nez)...

      ... ce qui permet par exemple d'expliquer pourquoi si on ne spécifie un codec que pour la vidéo avec "-y", on perd le son...

      Ou de se dire que si on utilise cette cochonnerie de lavc, sans spécifier de lavcopts, c'est peut-être parce qu'on utilise des réglages par défaut qu'on perd ostensiblement en qualité...
    • [^] # Re: Réponses

      Posté par . Évalué à 4.

      Mon but est l'archivage de vidéos en diminuant la taille des fichiers sans perdre trop de qualité.

      Je ne connais pas bien ni transcode, ni mencode, ni même le monde de la vidéo. J'ai juste constaté qu'avec un réglage par défaut (sans option particulière), mencode était moins bon.

      Maintenant, si il existe un réglage pas trop compliqué pour obtenir de bon résultat avec mencode, je suis preneur...

      Dans tous les cas merci pour cette réponse très enrichissante.
      • [^] # Re: Réponses

        Posté par . Évalué à 4.

        Le problème, c'est de savoir ce que tu appelles un bon résultat...

        Ca varie déjà pas mal d'une personne à l'autre... là où beaucoup vont se satisfaire d'un transcodage avec un faible bitrate sur du MPEG4-ASF, d'autres rechigneront à transformer un MPEG-II avec moins que du MPEG4-AVC, à la moitié du bitrate d'origine, et avec une pelleté d'options qui ralentissent de beaucoup le transcodage...

        Le bitrate à choisir va aussi dépendre de la résolution de la video : pour l'estimer, certains vont raisonner en bits par pixels, d'autres en bits par unité de la diagonale, ...

        Tout va aussi dépendre des codecs d'origine : ce sont quoi, les codecs, dans ta video, à la base ?

        Sans parler du scaling, pour fixer une bonne fois pour toutes l'aspect ratio (beurk), qu'il n'est pas possible de rentrer dans tous les conteneurs (le problème étant qu'une video scalée au transcodage, puis rescalée à l'affichage en plein écran, rendra forcément moins bien que si tout le scaling est fait à la lecture)...

        Bon, si ça vient d'un appareil numérique, gageons que la video doit être progressive, donc, tu n'auras probablement pas à désentrelacer (pourquoi yadif n'est-il pas multithreadé, ô monde cruel ?) ou faire de l'inversion de telecine...

        Bref, c'est tout sauf simple... surtout si tu cherches à optimiser dans le but d'archiver... Si tu veux vraiment en apprendre plus, j'insiste, mais la doc de MPlayer/MEncoder est géniale ( http://www.mplayerhq.hu/DOCS/HTML/en/index.html ), spécifiquement la section 14, et les diverses sections sur chaque codec.
        • [^] # Re: Réponses

          Posté par . Évalué à 3.

          Sur appareil photo c'est en general du mjpeg ou mpeg4 pour les plus recent.

          "La première sécurité est la liberté"

  • # ffmpeg ?

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

    Malgré son nom, as-tu essayé ffmpeg ?

    Il est très performant. Et made in France siouplait :-)
    • [^] # Re: ffmpeg ?

      Posté par . Évalué à 0.

      Pourquoi pas ...

      as-tu un exemple d'utilisation ?
      • [^] # Re: ffmpeg ?

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

        Pour les vidéos de mon appareil photo (ou même d'autres), j'utilise "ffmpeg2theora <video>", sans option particulière, ce qui me donne une vidéo Theora en sortie. C'est simple et efficace :)

        WeeChat, the extensible chat client

    • [^] # Re: ffmpeg ?

      Posté par . Évalué à 10.

      Et made in France siouplait

      Vu le nombre de personnes à travers le monde bossant sur ffmpeg ou des librairies dont il dépend, je trouve que c'est un argument un poil fallacieux...

      D'ailleurs, le projet est hébergé sur un site d'extension .hu

      Dans un écosystème libre avec des collaboration entre développeurs du monde entier, la notion "made in" n'est pas réaliste et va même un peu à l'encontre de cet esprit de collaboration.
      • [^] # Re: ffmpeg ?

        Posté par . Évalué à -1.

        Vu le nombre de personnes à travers le monde boss

        Petit à petit les frontières seront abolies grâce au libre et nous n'aurons bientôt plus qu'une grande nation terrienne.
        C'est le retour des utopistes humanistes.

        Grâce au libre et à sa philosophie, tout le monde se donnera la main pour former une chaine de l'amitié géante et il n'y aura plus de guerre. Et on se fera tous des bisous !

        Plus personne ne mourra plus du cancer, la Chine deviendra un précurseur dans le domaine des droits de l'Homme et on pourra guérir des doubles fractures combinées avec des pansements.ant sur ffmpeg ou des librairies dont il dépend, je trouve que c'est un argument un poil fallacieux...

        Ou chauvin ? ;)

        Dans un écosystème libre avec des collaboration entre développeurs du monde entier, la notion "made in" n'est pas réaliste et va même un peu à l'encontre de cet esprit de collaboration.
        Si si, on peut toujours dire "made in earth".


        Petit à petit les frontières seront abolies grâce au libre et nous n'aurons bientôt plus qu'une grande nation terrienne.
        C'est le retour des utopistes humanistes.

        Grâce au libre et à sa philosophie, tout le monde se donnera la main pour former une chaine de l'amitié géante et il n'y aura plus de guerre. Et on se fera tous des bisous !

        Plus personne ne mourra plus du cancer, la Chine deviendra un précurseur dans le domaine des droits de l'Homme et on pourra soigner les fractures avec de l'aspirine.
        • [^] # Re: ffmpeg ?

          Posté par . Évalué à 3.

          Mwais... soit... on peut prendre un ton ironique, voir sarcastique, reste que jouer sur le "made in", c'est faire un appel un poil malhonnête à la fierté nationale , et ça fait la négation des dépendances et des communautés gravitant autour du produit...
          • [^] # Re: ffmpeg ?

            Posté par . Évalué à 4.

            Mwais... soit... on peut prendre un ton ironique, voir sarcastique

            Mouarf...

            Tout ça pour ça.


            Un commentaire au 12e degré sans prétention aucune. Je conçois qu'on ne trouve pas ça drôle (c'est naze, j'avoue), mais qu'on dise de mon commentaire qu'il est moqueur, ça me ferait presque de la peine. ^^

            En général ce genre de commentaires passent bien :
            https://linuxfr.org//comments/659692.html#659692
            https://linuxfr.org//comments/698041.html#698041


            M'enfin continuez à moinsser sauvagement si ça vous défoule. La prochaine fois j'éviterais mes commentaires au ton "ironique, voir sarcastique" en me disant naïvement que ça fera peut être rire quelqu'un. De toutes façons je vais bouder ;)
            • [^] # Re: ffmpeg ?

              Posté par . Évalué à 3.

              mais non, reviens...

              désolé, je voulais pas te vexer...
  • # Si si, avec uniquement transcode ou mencoder c'est faisable.

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

    Tu peux utiliser transcode pour faire le son aussi :
    % transcode -i source.avi -y xvid,raw -o destination.avi
    Ça copie la bande son sans y toucher (c'est donc mieux que d'utiliser lame au niveau de la qualité).
    Les options de la compression xvid sont à mettre dans le fichier xvid4.cfg, que l'on peut générer avec xvid4conf (si il n'existe pas ça prend la valeur par défaut).
    Et si on veut aussi compresser la bande son, on peut toujours utiliser "-y xvid,lame".

    Pour mencoder, on peut utiliser "-ovc xvid" pour compresser en xvid, et l'option "-oac copy" pour ne pas toucher à l'audio :
    % mencoder source.avi -ovc xvid -xvidencopts fixed_quant=5 -oac copy -o destination.avi
    Les options se mettent dans xvidencopts.
    Et si on veut aussi compresser la bande son, on peut toujours utiliser "-oac mp3lame".

    Je n'aime pas trop faire le traitement audio et vidéo chacun de leur côté, on se retrouve parfois avec des soucis de désynchro.
    • [^] # Re: Si si, avec uniquement transcode ou mencoder c'est faisable.

      Posté par . Évalué à 6.

      > Je n'aime pas trop faire le traitement audio et vidéo chacun de leur côté, on se retrouve parfois avec des soucis de désynchro.

      Virer la video d'un conteneur (typiquement MPEG ou avi), ça ne craint pas... en ne gardant que le son dans le conteneur d'origine, on garde même l'éventuel offset que le son peut avoir (par contre, si on met le son dans un conteneur qui n'est pas fait pour la video [typiquement, un dump de la piste son], pour multiplexer de nouveau plus tard, oui, là, on risque des ennuis)... Heureusement, d'ailleurs, pour faire des mkv avec plusieurs pistes audio.

      ... par contre, il est capital (surtout avec des codecs modernes comme MPEG4-AVc) de conserver une piste son dans le même conteneur que la video à transcoder, quitte à la copier sans y toucher, et à la virer/remplacer plus tard, au multiplexage... sans quoi, la video risque de ne plus savoir quand supprimer/ajouter des frames, puisqu'elle n'aura plus de moyen de savoir de combien elle se désynchronise du son.
      • [^] # Re: Si si, avec uniquement transcode ou mencoder c'est faisable.

        Posté par . Évalué à 1.

        tres interessant...

        tu aurais un exemple avec quelques lignes de commandes (sortir la video du conteneur, traiter la video, remettre la video dans l'ancien conteneur) ou un lien sur les liens entre la piste son et image (naivement je pensais qu'elles etaient juste calees a 0 ensemble et totalement independantes...). Merci
        • [^] # Re: Si si, avec uniquement transcode ou mencoder c'est faisable.

          Posté par . Évalué à 6.

          Voilà comment je fais pour éviter la desynchro entre son et video qui est parfois importante.

          - T'encodes la piste video de ton fichier en copiant l'audio (faire les 2 passes)
          - tu extrais l'audio du nouveau fichier
          - tu encodes l'audio
          - tu mixes le tout dans un joli mkv.


          mencoder "tonfichier.avi" -oac copy -vf hqdn3d=4:3:6 -ovc x264 -x264encopts pass=1:bitrate=400:subq=7:partitions=all:8x8dct:me=umh:frameref=5:bframes=3:b_pyramid:weight_b:ssim:psnr -o video.avi

          mplayer "video.avi" -vc dummy -vo null -ao pcm:file=audio.wav

          oggenc -q 4 audio.wav -o audio.ogg

          mkvmerge -o "final.mkv" -d 0 -A -S "video.avi" -a 0 -D -S "audio.ogg" --track-order 0:0,1:0
          • [^] # Re: Si si, avec uniquement transcode ou mencoder c'est faisable.

            Posté par . Évalué à 6.

            Bonjour

            La dé_synchronisation son/vidéo intervient souvent lorsqu' on enregistre la télé cable(/adsl) par exemple. (courant aux USA et aux Canada semble t il...). La diffusion saute (effets de pixelisation / gel bref / autre ) et le decodeur s' en fout.

            Par contre lorsqu' on récupère cette vidéo et qu' on la transcode dans un autre format il est courant d' obtenir ce décalage son/images/

            Ce n' est pas pénalisant si on regarde son film sur son ordi, ou un Mplayer permet de gérer le décalage son/image comme on veut quant on veux... Par contre c' est pas joli :p et ch**** si on regarde cette galette sur une platine de salon ...

            ProjectX fait cette tache quasiment tout automatiquement (recaler son/image). http://project-x.sourceforge.net/

            Avidemux_{qt4,gtk} permet de reprendre ceci assez facilement, le plus dur étant de quantifier le décalage en milliseconde à vue de nez. (!) Ca marche à tout les coups et en 2 clicks. Perso je préfère la solution Avidemux_qt4 à ProjectX.
            • [^] # Re: Si si, avec uniquement transcode ou mencoder c'est faisable.

              Posté par . Évalué à 5.

              Bonjour,

              Un peu de hors-sujet, pour filer une info au passage: pour "deviner" le décalage son/image, il y à une méthode très simple:
              Quand tu charge le mpeg capturé, avidemux te demande de l'indexer. Il génère alors un fichier video.mpg.idx. Il suffi de faire un:
              tail video.mpg.idx
              pour trouver le décalage, par exemple içi -954ms (attention, signe à inverser dans avidemux):
              # track 1 PTS : 166610931 delta=0954 ms

              Par contre, cela fonctionne très bien... à condition que le décalage soit toujours le même. Si ce n'est pas le cas (cela m'est arrivé une fois déjà...), eh bien... je n'ai pas de solution (ProjectX ?).

              Sinon, je pense comme e-t172, si on one précise rien à mencoder, bin... il fait ce qu'il peut! Ah oui, et aussi mencoder r0><0r1z3 !
          • [^] # Re: Si si, avec uniquement transcode ou mencoder c'est faisable.

            Posté par . Évalué à 6.

            Ma méthode est un peu différente, et pour une raison particulière : je me sers de scripts pour faire de l'encodage massivement séquentiel, d'autant de choses que j'ai besoin, et à base de petits fichiers de confs individuels, ce qu'aucune GUI ne me permet :

            - rip (avec démuxage et sélection, soit des chapitres, soit d'un temps de départ et/ou d'une durée, les deux rentrant un tantinet en conflit),
            - puis transcodage,
            - puis multiplexage (dans du mkv, pour avoir des vobsubs et gérer proprement l'aspect ratio),
            - et enfin, éventuelle mise bout à bout des fichiers mkv (appending... gare ! : tous les lecteurs ne sont pas égaux devant ça - il vaut mieux avoir le même nombre de pistes et les mêmes index de langues, sans quoi, certaines [totem... pitit-pitit-pitit] pètent un plomb)...

            Du coup, je lance le script, je reste devant le temps qu'il ait tout ripé (ça peut être long, pour quelques saisons d'animes... saloperie de protection css - globalement, sur mon Q6600, qui ne tourne qu'à 80% lors de la deuxième passe, faute à yadif non multithreadé, et moins à la première, encore plus faute à yadif, vu que j'active l'option "turbo" sur le x264 sur cette passe, car ça ne change presque rien à la qualité, mais divise bien le temps de la première passe par 5, le simple rip des DVD me prend bien 20-25% du temps total), puis, je le laisse faire tout seul tout le reste.



            Alors, comme je prends génériquement en compte un éventuel découpage temporel de la video (par exemple, pour virer les pub sur les rips MPEG de la TNT, ou les petits clips sur les DVD de Strip-Tease, pas du tout calés sur les chapitres - NB : gaffe avec "-ss" et "-endpos" ; il ne faut les utiliser qu'aux limites d'une frame ; et attention à "-endpos", qui est la durée de la video, et pas la position de fin, si on a défini un début avec "-ss"), je ne peux pas me servir de -dumpvideo et -dumpaudio (par contre, vobsubout marche très bien avec la découpe - avec eux, puisque je n'ai pas envie de me taper de l'OCR sur des saisons d'animes [hors de question], le problème, c'est mkvmerge, qui a le comportement idiot de les multiplexer par défaut, même quand on fait juste de l'appending, en les compressant avec zlib, ce qui n'est pas supporté par, notamment, mythvideo, le lecteur de mythtv - ce qui est très chiant, d'autant plus que pour réparer ces conneries, il faut se taper la rectification piste par piste)...

            ... du coup, je copie la video non transcodée avec la première piste son dans un conteneur avi, et toutes les pistes audios non transcodées qui m'intéressent, chacune dans son conteneur avi séparé, sans la video.

            Pour le rip/démultiplexage, plus explicitement, pour la video :

            mencoder dvd://${TITLES} ${CHAPTERS_PARAM} ${START_POS_PARAM} ${DURATION_PARAM} -oac copy -ovc copy -o "${TO_ENCODE_FILES}/${NAME}.video"

            et pour l'audio :

            mencoder dvd://${TITLES} ${CHAPTERS_PARAM} ${START_POS_PARAM} ${DURATION_PARAM} -aid "${AID}" -oac copy -ovc frameno -o "${TO_ENCODE_FILES}/${NAME}.${AID}.audio"



            Après, je transcode la video en gardant toujours la première piste audio (que je ne veux même pas forcément), pour qu'il ne se perde pas (j'utilise toujours au moins un "-vf softsktip,harddup", avec les éventuels filtres de désentrelacement/inversion télécine, et le cropping) ; je garde généralement la piste audio telle quelle, n'y ayant pas tant que ça à gagner de ce côté, puisque c'est déjà compressé - à la limite, si je voulais vraiment gagner de la place, je prendrais plutôt la piste 2 canaux AC3, plutôt que la 5 canaux... mais sinon, vu la taille du reste, je ne suis vraiment pas à quelques dizaines de Mio près (en H.264, je transcode avec un bitrate de référence de 2800kbps, et des bits par unité de diagonale constants, relativement à une video de 1024x576@25fps, une fois l'aspect ratio appliqué et le cropping effectué, soit grosso merdo la moitié de la taille de la video d'un DVD lambda pour du 16:9 anamorphique... ça fait gros, mais pour faire la différence avec le DVD, surtout avec deux passes et des options un peu bourrines, faut vraiment se lever tôt)...



            Enfin, je multiplexe le tout (dont aussi les chapitres, que je chope avec dvdxchap, et que je charcute à-la-hard pour prendre en compte les décalages temporels s'ils ont été spécifiés), en demandant à n'avoir que la video sur le fichier .video, et itout pour le reste... et ça marche : je n'ai jamais eu de grossier décalage audio/video (il y en a toujours un peu, les chunks audio à 48kHz ne correspondant jamais à la durée des chunks video à 24/25/30000:1001fps, mais mencoder supprime/duplique des frames au besoin, pour éviter les désynchro énormes - pour voir le mini décalage au fur et à mesure des opérations, zieute sur le petit "A-V" qui a la bougeotte, à droite de la ligne qui donne le temps et les fps, dans MEncoder et MPlayer, et qui n'est pas censé dépasser la durée de deux frames video... on peux trouver plus d'explications, et notamment l'impérieux conseil de ne pas traiter la video après lui avoir fait un "-of rawvideo", dans la doc de MPlayer/MEncoder, que j'ai donnée en lien au-dessus, beaucoup plus complète que la page de manuelle, déjà vertement touffue)...

            En bref, pour conclure, oui, l'archivage propre, c'est plutôt compliqué...
  • # Pour conclure

    Posté par . Évalué à 1.

    Finalement j'ai choisi ffmpeg2theora. Pourquoi ?

    1. une commande simple à écrire et à comprendre :



    % ffmpeg2theora -p pro --optimize source.avi --output destination.avi



    2. Une qualité conservée, à l'oeil on peut remarquer seulement des couleurs légèrement moins vives.

    3. Un gain de place non négligeable. Sur un échantillon de 104 fichiers avi pour un volume de 3,4 Giga, on obtient 104 fichiers ogg pour un volume de 1,4 Giga

    Merci à tous.

    FIN

Suivre le flux des commentaires

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