[TOPIC OFFICIEL] Codecs Video et Audio pour DivX

Logiciel & apps Logiciel Multimédia
582

A aprt ça, juste un mot sur le test de Doom9, sur lequel je suis assez d’accord, et j’ajoute mon avis subjectif à 200% qui ne vaut que ce qu’il vaut :wink:

  • Divx, payant et à peu évoluer en 2004 et interface de configuration du codec que je n’aime pas. Le rendu me semble inferieur au Xvid (codec payant rappellons-le hein :wink: )

  • XviD, gratuit, rapide, excellente qualité, interface de configuration sobre et enfin avec une version stable !!!

  • RV: toujours incompatible VFW donc pas de virtualdub. Rendu ambigue mais de bonne qualité… pour moi c’est l’exemple type du codec de type: je floute bcp donc je suis beau. Encodage assez lent, bref il y a ces amateurs, et ces detracteurs dont j’en fait partie.

  • VP6: la bonne surprise de l’année ! Excellent rendu gratuit, puis… payant (Vp aime la peche: il amorce et apres il ferre !). Excellent rendu, qui a mes yeux un compromis visuel qui se rapproche bcp d’un mix entre RV et Divx, avec un effeft “sharp” assez chouette. Codec avec une interface clair, et compatible VFW :slight_smile:
    L’inconvenient est sa lenteur d’encodage, sinon c’est presque parfait !

  • H264: Trop récent pour l’utiliser, mais c’est evident que c’est le futur, et bientot le present, en 2005 (fin 2005?) ça devrait pas mal evoluer surtout avec le Nero DG, sans oublier de surveiller les projet open source :wink:

Donc pour moi Ze winner is:

XviD 1.0.3, élue meilleur codec video 2004 !
VP6 en 2eme.
et Divx en 3eme.

En attendant le H264 et “fin 2005 / courant 2006” des petit codec supportant les petit cpu dual core que amd nous vendra pas trop cher :slight_smile:

Ont peut rever…LOL

583

[:likairui] Sokarz ^^

L’article sur Mpeg4 Modifier est bien alléchant :slight_smile:
Mais quelle galère de de devoir rebooter sur $#$@£µ (bon j’ai la flemme d’ouvrir man mencoder aussi faut dire)

Bien vu tes réponses sur les esapces de couleur. pas tout pigé mais ça resterai impénetrable sans ton aide alors merci SokarZ :jap:

Tes conclusions perso sur les codecs “tested by Doom9” sont celles de Doom… légèrement influencées par l’aspect Rapidité*/Qualité/OpenSource de XviD, non ?

Rien de nouveau chez Project: Avisynth on Linux :frowning:

  • Heu, pour l’encodage du 700Mo qu’était mal encodé (640327 au lieu de 640480) g t à qlqs FPS et 12H (sans l’audio) sur un athlon xp1800+ :heink:
    D’ailleurs, la partie de l’article Doom9 sur le FPS (qualité / rapidité, un paragraphe qui t’a peut-être plu) est pas super claire : [FPS à 50 = bon ; FPS <25 = pabon]. Quequ’un a un lien pour nioubie siouplait ?
584

Pour faire une analogie très simple, les espaces de couleurs video comme rgb ou yv12, peuvent être comparé à la pao avec le rgb et le cmjn, ce n’est qu’une analogie ne pas prendre ça “à la lettre” :slight_smile:

Ce que je sous entends c’est que parfois quand lors d’un encodage (meme en une passe par ex.) on utilise plusieurs plugin qui utilise (et ne fonctionne) qu’avec l’espaces colorimetriques pour lequels “tel plugin est fait pour”, il s’agit d’ailleurs plus (+) d’une (triste) limitation technique dudit plugin que d’un réel besoin :frowning:

exemple concret, mais je precise que ce n’est peut-etre pas ton cas !?

un script avisynth bebete utilisant deux plugin necessitant deux espaces colorimetique et donc besoin de faire une double conversion sans quoi l’un des deux plugin ne marchera pas (si l’un ne fonctionne que avec le mode X et l’autre que avec le mode Y).

le meme script sans les affreux commentaire:

Voilà pourquoi on evite autant que possible, de faire des conversions d’espace de couleurs, car avec ces bestioles on peut avoir des surprise de type le rouge vif devient violet, etc…

Note:

Dans Vdub (ou Vdubmod) quand on utilise:

  • Video > Full compressing mode
    on encode en RGB

  • Video > Fast recompress
    on encode en YV12 (si on utilise un codec qui peut encoder en YV12: xvid, divx par ex fonctionne en yuy, yuy2, et aussi yv12 donc no pb avec ces codec pour encoder en yv12).

A savoir que la plupart des dvd sont encoder nativement en YV12, c’est pourquoi on s’acharne durant la phase d’encodage du “divx” d’eviter au maximum les conversions de type YV12 -> RGB -> YUY2 -> RGB -> YV12

Conclusion: éviter d’utiliser des plugin nécessitant de changer d’espace de couleurs, sinon risque de resultat parfois un peu etrange…

Voilà, ouf ! Et hop un long post de plus pour surcharger un peu plus la “bdd” de clulu :slight_smile:

[:-jaja-]

585

Franchement ? Oui :slight_smile:
Car gratuité et efficacité, pour ma part c’est très important ! Aspect psychologique certes, mais bon après tout pourquoi payer, si ont peut avoir la meme chose gratuitement ET légalement !?

Idem pour le H264, vivement des bon codec H264 open source (ou au moins freeware) stable et performant ! Par contre je me vois mal payer 50 ou 200$ un codec loooool… et utiliser un codec “cracké” alors qu’une alternative legal, performante et gratuite existe, bé dans le fond, c’est “dommage” (pour rester poli lol).

Quand au RV je ne dis pas que c’est un mauvais codec, je l’ai deja utiliser (sur des dvd stargate à 176 mo/episode en 576x320 de memoire + ogg le rendu est excellent meme si trop flouter aucune pixellisation, bref…), le RV est “gratuit” et à ce titre je prefere le RV au Divx payant, meme si je prefere avant tout le XviD car compatible Vdub, ce qui n’est pas le cas du RV…

Tout ces codec ont leurs defaut et qualité, passer les 650 kb/s j’utilise le Xvid, et en dessous du VP6 ou RV.

Niveau rendu, une chose est évidente TOUT ces codec sont excellent ! Meme si ils ont des rendu different -> ils sont tous excellent :slight_smile:

C’est l’utilisateur qui peut etre heureux car fini le temps du divx3.11 et des 1150 kb/s pour faire un truc pas trop pourri…

:ange:

586

J’oubliais…

Avisynth 3, c’est encore en cours de devellopement, comme toi, j’espere que ça sorte vite en version au moins beta…

Wait and see, pas le choix !

Et ? Tu sous entends que le meme encodage en 640*480 ça carburait niveau vitesse d’encodage ?

Hum, disons que avec certain plugin/crop/resize qui ne respecte PAS (en largeur et/ou hauteur) la taille video (le fameux chiffre multiple de huit) -> ça peut faire bugger un plugin, et donc dans ce cas , les fps d’encodage ça chuuuuutte, voir pire: foire l’encodage (ex: defaut dans l’image de type barre verte, etc…)

Il suffit de respecter le “fameux” chiffre multiples de huit (8) quand tu choisis “tel ou tel” resolution, et hop plus de pb :slight_smile:

genre pour la largeur: 576 ou 640
car 576 ou 608 ou 640 sont des chiffres eux meme multiple du chiffre 8. C’est pour ça que Gordianknot propose des resolution basé sur 640, 608, 576, etc… Pour eviter ce type de bug/probleme.

En general si un plugin est limiter par ex, à un chiffre multiple de “8” c’est preciser dans le readme.txt du plugin.

Concretement 99% des encodage se passe bien en utilisant des plugin “classique” avec un chiffre multiple du chiffre 4, sinon au pire un bon vieux 576 ou 608 et c’est ok :slight_smile:

Les chiffre multiple de “2” posent aprfois pb avec certain plugin…! Donc avec 4 ou surtout 8, on a jamais de pb :slight_smile:

C’est simple… Doom aime pas attendre c’est un grand stresser LOL il sous entends, tout simplement que plus le codec est lent à encoder, plus c’est chiant d’attendre, et que plus le codec est rapide à encoder, moins tu te fait chi*er à attendre la fin de l’encodage !

Il precise aussi que un encodage rapide ne rime pas avec qualité mediocre, et inversement, que un encodage lentissime ne rime pas avec qualité maximal pour autant.

Ex: XviD: rapide et zoli. Divx lent et joli…

Ont peux donc sous entendre que “vu que c’est joli dans les deux cas” autant encoder en Xvid qui fera le meme resultat voir mieux, mais 2x plus rapidement que le divx.

Evidemment il n’y a pas de regle ultime, donc c’est tendancieux quand meme, car tout depend de “tel options activé sur tel codec”, une option decoché ou pas, et c’est vite 10% de vitesse perdu ou gagner.

Donc bon ce genre de comparo faudrait les faire en deux test:

  • test1 avec toutes les options activé qui “bouffe du cpu”.
  • test2 avec toutes les options DEsactivé qui “bouffe du cpu”.

Et puis on y verrait deja plus clair :slight_smile:

Et enfin comme je l’ai toujours dit, ce qui compte c’est “sa” propre experience, basé sur ces propre test ^^

En ce qui me converne: XviD + avisynth avec le plugin HybridFupp, c’est LE meilleur compromis qualité/vitesse respectable…

587

[#008d71]> la plupart des dvd sont encoder nativement en YV12, c’est pourquoi on s’acharne durant la phase d’encodage

du “divx” d’eviter au maximum les conversions de type YV12 -> RGB -> YUY2 -> RGB -> YV12

Tout ces codec ont leurs defaut et qualité, passer les 650 kb/s j’utilise le Xvid, et en dessous du VP6 ou RV.[/#008d71]

Je prends des note (et me rencarder sur RV + Ogg, même si ya des chances que je fasse de + en + avec mencoder/Avidemux & lavcodec)

Et ? Tu sous entends que le meme encodage en 640480 ça carburait niveau vitesse d’encodage ?
Nan! je mal exprimer moi :wink:
Je voulais te dire que g t supris par la durée du ré-encodage en 640480. Autrement dit, que l’encodage du 700Mo (celui qui était mal encodé en 16/9 : 640327 au lieu de 640480) prenne >12H (sans l’audio) sur un athlon xp1800+ !-(

Voilà, ouf ! Et hop un long post de plus pour surcharger un peu plus la “bdd” de clulu :slight_smile:

Excellent, nan sans dec tu expliques de mieux en mieux et je te le dirai tant que tes chevilles resteront de taille moyenne :slight_smile:

Sinon j’ai [b]corrigé l’aspect ractio des 2 x 700Mo<·g]
J’avais pas envie d’installer “.Net Framework” pour pouvoir installer “Mpeg4 Modifier”, donc j’ai fini par jetter un oeil sur la doc de mplayer/mencoder. 20’ tout compris + tard j’ai mes 2 x 700’ corrigés en 4/3 (sans devoir rien installer de +) :

[#0e00f0] “MPEG-4 a une fonction spécifique: le flux vidéo peut contenir le ratio d’aspect requis. Oui, tout comme les fichiers MPEG-1/2 (DVD, SVCD) et H.263. Malheureusement, il n’y a aucun lecteur vidéo qui supporte cet attribut. Excepté MPlayer.”

"Cette fonction ne peut être utilisé qu'avec le codec mpeg4 de libavcodec. /!\ même si MPlayer lit correctement le fichier créé, les autres lecteurs continueront d'utiliser le mauvais ratio d'aspect."[/#0e00f0]

La correction m'a pris <5' pour 700Mo, avec la commande ci-dessous

=> mencoder [fichier_vidéo_mauvais_ratio] -ovc copy -oac copy -force-avi-aspect 1.33 -o [fichier.avi] :P

[EDIT] Cerise sul’gâteau, les fichiers corrigés font chacun 3000 ko de moins :slight_smile:

588

Pour ce qui est du reseize d’une video par info dans le container le MKV gere les ratios et ca marche parfaitement.

Par contre pour ce qui est du test des codecs par doom9 j’ai deja fait un topic y a longtemps (a sa sortie en fait) et j’ai eu 0 reponse, le beau vent…et je suis assez etonné de voir cette discution ici sur un topic deja surchargé par sa generalité (ce qui n’est pas une critique c’est une bonne synthese :))

http://forum.clubic.com/forum2.php?config=clubic.inc&post=20895&cat=12&cache=&sondage=0&owntopic=1&p=1&trash=0&subcat=0
j’aurais bien aimé qu’on en papotte…mais bon soit.

589

MKV ?
J’ai même pô encore essayé d’en faire :frowning:
Faut que je vois ça !

Pour le comparatif, bah vi plus rapide Morcok, & avec un résumé pô mal !
maintenant le 30/12 perso j’avais des chtites choses à préparer alors cluclu…

590

Le matroska depuis que c’est vraiment stable je fais plus que ca, c’est ultra pratique, souple au possible…

Le seul defaut c’est la gestion des SUB/IDX qui pue de la bouche (on peut plus les extraire).

C’est Sokarz qui nous en avait parlé au debut et il avait franchement pas tord (moi j’ogmisait a ce moment :p)

591

J’ogimisait aussi à l’époque, mais dès le debut j’avais esayer le mkv et c’est vrai que dès qu’on veut encoder une video Et plusieurs pistes audio et/ou sous titres, le matroska s’impose de lui-même :slight_smile:

Euh Pour ton topic, le 30 j’etais pas là, je l’avais pas vu ton topic ;(

592

Salut et bravo pour ce TO !

J’ai juste une petite question concernant le “Satsuki Decoder Pack”.
Une installation par défaut suffit-elle ? Ou bien est-il préférable de tout sélectionner lors de l’installation ?
Je précise que je fais que lire (et non encoder, ce traval est fait par mon frère) et que j’utilise Winamp pour les fichiers audio (ainsi que Winows Media Player occasionnellement).

Merci encore et bonne continuation :P.

Edit: faut-il installer RealPlayer et QuickTimePlayer ? J’ai vu que le pack contenait un décodeur pour les fichiers Real, mais qu’en est-il des fichiers QuickTime ?

593

salut! je me permet de reposer une troisième fois la même question au sujet de la taille finale d’un fichier en xvid qu’on a a encodé. le rapport hauteur/largeur doit respecter des règles ou bien la hauteur et la largeur doivent être un multiple de 2 ou 4 par exemple? merci

594

hum disons que si c’est toi qui encode je te recommande chaudement des multiples de 32 car c’est avec ca que le codec est le plus a l’aise.

Apres c’est minimum 2, mais au plus c’est haut au mieux c’est, moi je fais du 32X 32X en cropant legerement pour garder un bon ratio.

595

merci. je l’avais réalisé quand je voyais par exemple le rv10 qui marchait bien si on respectait les multiples ( c’est indiqué sur le codec ) mais pour le xvid rien d’indiqué, et j’obtiens qu’une fois sur 2/3 la taille finale désirée. et je trouve que le xvid 1.0.3 de koepi offre une super qualité pour un temps d’encodage rapide comparé au rv10 ou vp6. j’ai même l’impression que la différence de qualité entre le xvid 1.0.2 et 1.0.3 est bien visible -> d’où mon intérêt à préférer ce codec pour l’instant

596

bon je viens d’essayer avec un ratio de 3216 et rien, la taille finale est identique à quelques centaines de ko près à un ratio de 22. le pire c’est que la taille finale est environ égale à 50 à 70 % de la taille souhaitée!

mais parfois ça marche! que je mette une fonction trim ou non dans le script. il y a donc forcément au moins un réglage en dehors du codec qui fait coincer le basard.

dommage car avec le divx ou le rv10, j’obtiens toujours la taille finale désirée et ce avec le même script. le vp6 se fout un peu de moi aussi comme le xvid mais la taille finale obtenue est de l’ordre 95/105 % donc c’est nettement moins gênant ( et toujours avec un script identique )

597

tagada67:

Euh… tu coche les options que tu veux installer :slight_smile: A part le mp3 et mpeg1 (vcd) windows d’origine ne lit pas grand chose. Donc à toi de savoir :

  1. avant d’installer satsuki, qu’a tu installer d’autres qui peut avoir installer un codec ou filtre directshow dans windows.

  2. Sachant ce qui manque, il reste plus qu’a installer, ce qu’il te … manque !

  3. Au pire tu installe tout dans le toute: no pb.

C’est bien simple: essaye :slight_smile:

  1. Installe Satsuki, ouvre un fichier Real et…ohhh magie ! Pour le format mov (quicktime) installe quicktime player.

ps: tu peux en plus de satsuki installer real alternative, car il me semble que par exemple en utilisant uniquement le filtre directshow real, le streaming ne marche pas (à vérifier ! je dis peut-etre une barthezerie !!!

598

the coco :stuck_out_tongue:

T’as un pb sur ton pc, ou bien tu utilise très mal une option du xvid, ou voir tu utilise des réglages très différents entre la 1ere et 2eme passe. C’est trois raison cité: pb pc, mauvaise utilisation, mauvais reglage, peuvent faire dériver la taille du fichier.

  1. Probleme pc, bon là on peut pas trop t’aider, les raison du pb peuvent être innombrable, desinstalle le xvid 1.0.3, redemarre windows, reinstalle xvid 1.0.3 (comme d’hab version koepi).

En utilisant par exemple: xvid 1.0.3, Virtualdub(Mod) en derniere version, Gordianknot 0.33, Avisynth 2.5.5

Voilà avec ces soft, il n’y a aucune raison que ton fichier devie de plus de 500ko pour environ 700mo.

Hormis une source video très bizarre, ce qui arrive une fois sur cent voir plus, tu ne doit pas avoir ce pb !!!

Modulo par 32 = parfait !
modulo 16 = très bien
modulo 8 = bien
modulo 4 = assez bien
modulo 2 = risquer ! car certain plugin avisynth ne fonctionne que avec un modulo de 4 voir plus rarement 8.

Gordiannot par defaut utilise un modulo de 32 (larg.) et 16 (haut.).

Perso je preconise de cropepr par “pas de 4” et d’utiliser un modulo de 16. Et pour faire ça, d’utiliser GordianKnot pour faire le script avisynth en mettant un modulo de 16 dans l’onglet Resolution de Gk, et d’utiliser un crop avec un “pas” de 4 (4, 8, 12,16…60,60,64,68,72, etc…)

Ensuite le script tu le modifie dans le blocs notes par ex. et tu encode “à la main” avec Vdubmod, perso j’ai toujours fait ainsi…

Autre chsoe evite els valeurs impair pour ta largeur/hauteur ! Le but c’est d’encoder avec un modulo 16, avec un crop “multiple de 4” (voir 8 ou 16 ! Donc si tu encode en 577 x 305 au lieu de 576 x 304 par ex, c’est sur que c’est pas très bon !

De meme le crop ! Evite les crop de genre:

haut: 67
bas : 63
droite: 5
gauche: 12

67+63 = 130 donc tu pourrai me dire héééé mais 130 est un chiffre pair ! Donc je peux utiliser u nchiffre impair comme 67 si avec 63 ça donne un chiffre pair ! Et je dis oui,… en theorie ça ne pose aucun pb ! Mais ! Certain plugin n’aime pas les crop impair et 67 est un chiffre impair meme si le cumule de haut + bas = pair, c’est une source de bug eventuel !

En clair:

  • la résolution haut*larg. choisi avec un modulo de 16 (512, 576, 608…)
  • le crop par pas de 8, ex crop haut = 64, crop bas = 72, crop droit = 0, crop gauche = 8

ps: le tout en visant aucune deformation de l’image :stuck_out_tongue: “Erreur aspect” dans Gk/Resolution doit etre à 0.0% si possible maxi 0.4%

avec un script avisynth (sans erreur :P), et en encodant avec Virtualdubmod 1.5.10.1 build 2439 + xvid 1.0.3, je n’ai jamais eu de pb de taille à atteindre et ce quel que soit le codec y compris avec le xvid que j’utilise dans 99% de mes encodages video :slight_smile:

(mis à part du à un bug du codec utilsier quel qu’il soit mais depuis 2003 plus de pb de ce type).

Voilà, à part te redire “ces bases” je ne peux pas dire grand chose d’autre, eventuellement repost ton script avisynth (epuré des commentaires de type # blabla) des fois qu’il y ai une coquille ?

Et decrit ta manip d’encodage de A à Z on verra peut-etre la couil*e ?

599

ok je te remercie pour ton aide bien précieuse :slight_smile:

je n’utilise pas de nombre impair ça non, et oui j’avais pris l’habitude d’utiliser virtualdubmod ( enfin pour le trio gagnant xvid/vp6/divx -> ma préférence perso avec le rv10 similaire au vp6 )

mais même avec ripp-it, c’est toujours pareil, enfin une fois sur deux ou sur trois. donc le log utilisé n’a rien à avoir. et puis ripp-it utilise aussi virtualdubmod si on encode pas en rv10. la source de la video: mes videos capturées en mpeg2!

mais comme je l’ai dit, en divx/rv10, pas de blème et en vp6, problème similaire mais fort moins génant ( je me donne une petite marge d’erreur de 5 % ). mais dans tous les cas, la seule chose que j’aurais modifiés dans les codecs, c’est de dire que,ma video n’est pas entrelacée mais du genre ’ progressif’. car entrelacer avec un script alors que le codec le fera aussi donne un effet de flou je trouve. mais même, si je change pas ce détail, ça change rien sur la taille finale.

je ne pense pas que le problème vienne du pc, je regrette car avant de changer ma carte mère, j’avais déjà le même problème. et je suis comme un maniaque du rangement/propreté sur ordi: diskeeper au moins une fois par jour, tous mes logs de prévention mis à jour continuellement ( antivrus, les anti-spywares et nettoyage du registre ), je surfe avec firefox, je ne vais pas sur les sites déconseillés ( enfin tu vois ce que je veux ), je n’utilise pas le p2p (et donc pas kazaa par exemple).

mais si je me trompe pas, un rip de dvd a toujours bien marché avec le xvid… bizarre hein.

et si je ne dis pas de bétises: le mpeg2 compressé avec les plug’in présents dans ripp-it ( ce que tu conseilles d’ailleurs comme étant la méthode d’encodage ultime, le ‘HybridFuPP’ je crois bien ) a bien marché aussi même avec le xvid ( d’ailleurs c’est plus lent mais je ne me souviens plus réglage que j’ai fait lol, mais j’avais l’impression que le fichier final était de meilleure qualité que le mpeg2 d’origine!! )

Disons qu’en gros, j’utilise en fait ce script issu de GK:

LoadPlugin(“C:\PROGRA~1\GORDIA~1\AviSynthPlugins\dgdecode.dll”)
LoadPlugin(“C:\PROGRA~1\GORDIA~1\AviSynthPlugins\decomb.dll”)
LoadPlugin(“C:\PROGRA~1\GORDIA~1\AviSynthPlugins\UnDot.dll”)
LoadPlugin(“C:\PROGRA~1\GORDIA~1\AviSynthPlugins\Convolution3d.dll”)

clip=mpeg2source(“E:\video\film.d2v”).crop(6,6,698,564)
var1=clip.trim(0,37675).FieldDeinterlace().LanczosResize(520,420).Undot().Convolution3d(“movielq”)
var2=clip.trim(47245,144053).FieldDeinterlace().LanczosResize(520,420).Undot().Convolution3d(“movielq”)

Return var1+var2

le mpeg d’orgine a une résolution de 720*576 pixels. l’exemple ci-dessus concerne un film sans bandes noires ( bandes parasitées sur le bord de l’écran )et qui contient une pub au milieu. je prend les valeurs du cropping et la résolution directement à partir du script issus dans GK. et oui, mes video capturées sont toujours entrelacées!

mais dans certains cas où j’utilisais ripp-it avec les plug’in fournis, je faisais un peu comme dans GK, il établit lui-même le script mais la syntaxe est un peu différente ( sans doute à cause du ‘HybridFuPP’ ) et je n’ai pas trouvé le moyen de ‘trimmer’ avec cette syntaxe. dommage que unité-video n’ait plus d’hébergement, et je ne maitrise pas aussi bien bien l’anglais que le français ( snif snif! )

600

Pas besoin de codec: Utilisez VLC Média player !

601

:heink: