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 ragoutoutou . Évalué à 10.
[^] # Re: x264
Posté par bubar🦥 (site web personnel) . Évalué à 7.
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 Quzqo . Évalué à 2.
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 bubar🦥 (site web personnel) . Évalué à 2.
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 Quzqo . Évalué à 1.
[^] # Re: x264
Posté par nicoastro . Évalué à 3.
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 briaeros007 . Évalué à 4.
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 IsNotGood . Évalué à 4.
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 seginus . Évalué à 2.
Quelqu'un peut-il apporté des éclairssicements ? ai-je mal faux sur un point ?
[^] # Re: x264
Posté par e-t172 (site web personnel) . Évalué à 1.
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 ragoutoutou . Évalué à 4.
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 Aefron . Évalué à 3.
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 e-t172 (site web personnel) . Évalué à 10.
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 Aefron . Évalué à 5.
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 touv . Évalué à 4.
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 Aefron . Évalué à 4.
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 Nicolas Boulay (site web personnel) . Évalué à 3.
"La première sécurité est la liberté"
# ffmpeg ?
Posté par Kerro . Évalué à 4.
Il est très performant. Et made in France siouplait :-)
[^] # Re: ffmpeg ?
Posté par touv . Évalué à 0.
as-tu un exemple d'utilisation ?
[^] # Re: ffmpeg ?
Posté par FlashCode (site web personnel, Mastodon) . Évalué à 4.
WeeChat, the extensible chat client
[^] # Re: ffmpeg ?
Posté par ragoutoutou . Évalué à 10.
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.
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 ragoutoutou . Évalué à 3.
[^] # Re: ffmpeg ?
Posté par ß ß . Évalué à 4.
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 ragoutoutou . Évalué à 3.
désolé, je voulais pas te vexer...
# Si si, avec uniquement transcode ou mencoder c'est faisable.
Posté par Damien Thébault . Évalué à 4.
% 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.aviLes 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 Aefron . Évalué à 6.
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 RB . Évalué à 1.
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 hokata . Évalué à 6.
- 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 bubar🦥 (site web personnel) . Évalué à 6.
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 Christophe --- . Évalué à 5.
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 Aefron . Évalué à 6.
- 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é...
[^] # Re: Si si, avec uniquement transcode ou mencoder c'est faisable.
Posté par Aefron . Évalué à 2.
# Pour conclure
Posté par touv . Évalué à 1.
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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.