TRADUCTION :

mon premier test avec XviD 1.1.0beta1 va me faire un fichier 2 fois plus petit que demandé, même si le film est sombre et donc très compressible.
En plus il tourne 2x moins vite que la normale. Ne serait-ce pas parce que j'ai coché VHQ sur les images bidirectionnelles ? Ou serait-ce parce que j'ai activé le trellis de combat du quantizer ?



bon je confirme : 350 Mo / 700 demandés à 1 heure de la fin...

Si l'undersize se confirme, fais un test de compressibilité, c'est surprenant les résultats parfois....

Je fais systématiquement ce test maintenant et bon nombre de mes certitudes sont "tombés" avec les résultats de ces tests

1.1.0beta1 - profil DNX HT PAL + VHQ 1 coché sur B-frames + mini quant à 2 + trellis
12h => 390 Mo @ 500kbps / 700 demandés (à 1000kbps, rapport bit/pixel = 0,13, 77 Mo de son)
L'image est quand même d'excellente qualité => film très compressible à vue ne nez, mais pas tant d'après le test : 0,16 dit le test, soit 80% avec mon rapport bit/pix à 0,13

1.1.0beta1 - profil AS@L5 - matrice MPEG + VHQ1 coché sur B-frame + mini quant à 1 - pas de trellis
10h => 780Mo @ 1150 kbps / tjrs 700 demandés
ah bon, oversize quand même... Image un chouia plus nette, logique...

est-ce le "trellis quantization" qui rallonge d'autant ? (puisque l'encodage avec la matrice MPEG est logiquement plus lent qu'avec la matrice H263 du profil DNX) ?

j'ai bricolé les deux fichiers pour avoir mes 700 Mo et je vais passer à un autre film pour tester la bêta... et revenir au 1.0 si ça cafouille encore...



sinon : la matrice peut être choisie même en DNX : il suffit de passer en AS@..., de choisir la matrice, et de revenir en DNX (du moins ça apparaît comme ça dans la fenêtre grisée).

Pour le trellis c'est surprenant, je ferai un essai d'encodage avec et sans pour voir la différence de temps...

J'ai rien compris aux chiffres concerant le test de compressibilité. Le test tu l'as fait avec quel logiciel ?

Ca va les fous de XviD ???

très bien merci




ben avec ripp-it tiens !
0,16 c'est la compressibilité (qui est censée indiquer le rapport bit/pixel idéal, si j'ai bien compris)
80% c'est le rapport entre celle-ci et mon rapport de compression bit/pix (1000kbps pour 640*496 pixels), enfin l'inverse : 0.13/0.16=0.80=80% : soit la qualité obtenue sera de 80% de laqualité maxi "obtenable" ("obtensible" ?)
résultat : fichier de 54Mo sur 5% testé = 1080 Mo si on encodait à plein régime et qualité maxi et quant mini avec le XviD (toujours si j'ai bien compris)
Par contre j'ai fais le test avec le codec réglé en AS@L5 avec matrice MPEG et quant mini à 1, ce qui n'est peut-être pas représentatif...

Le test de compressibilité n'est (pas encore) optimum dans cette version. De mémoire il ne tient pas compte du script avs et la répartition de l'analyse a des mailles trop grandes.

A mon avis perso, tu ne peux pas te fier au résultat (avis perso, j'insiste et qui n'engage que moi, je ré-insiste....)

Voir le lien donné plus haut pour une alternative à RIAM afin de faire un test de compressibilité en XviD

bon j'aurais du lire les tutos avant de parler, j'ai mis les I/V/B frames a 2 et tout de suite, tout rentre dans l'ordre, taille parfaite

Tu es avec quelle version de XviD ?

1.1.0 probablement puisque le pb de taille non respectée avec les quant à 1 "semble" réglé dans la 1.0.3. Enfin, ça reste à voir...




j'aime bien les "pincettes" de Stryke à propos du test de compressibilité...

Bon, je vais tester ARC aussi grace à ton exxxxxcellent tuto

sinon : encodage d'un court expériemental (genre "flicker" et flash stroboscopique où chaque image est à 99% différente de la précédente avec plein de couleurs flashy). BR à 3000 : respecté avec 1.1.0 : aucun pic au-delà de 4000k. Chouette le VBV en XviD. Ça passe comme une lettre à la poste sur KiSS

ouais par contre j'ai remis la vieille 1.0RC4 qui me restait sur mon dur. Je vais réessayer avec la toute dernière beta et je verrais ce que ça donne

Une question, j'avais lu un temps que la matrice mpeg était a proscrire sur une source mpeg (2), risque de reproduire en agravant les défauts d'encodage... Vrai ou pas ?
Le H263 offre moins de blocking et de ringing mais est plus flou que la HVSbest (qui a tout l'opposé en faite).

Le rapport bit/pixel ne veut pas dire grand chose si on ne précise pas le type de film encodé a premiere vu. Ce rapport de tient pas compte du bruit, de la luminosité, du mouvement, quantité de détail...

Sinon, le bVHQ ralentit quand même l'encodage, mais peut-etre (ca reste subjectif) block moins sur les mouvements.

salut, merci pour l'info sur bVHQ. Si on parlant du rapport bit/pixel tu fais référence à celui donné par le test de compressibilité, à priori il est significatif puisque c'est celui de la vidéo "test" encodée avec le débit maximal nécessaire pour la vidéo, prenant donc en compte mouvement, contrastes etc. Sinon, effectivement, il n'est pas très représentatif (un peu que le seul débit quand même puisqu'il prend en compte la résolution de la vidéo). Pas lu sinon que la matrice MPEG était à proscrire pour encoder une source MPEG2...

2 nouveaux tests avec le XviD1.1.0b : 702 Mo respectés, comme demandés. Ouf... Ben elle a l'air très bien cette beta...

et ben, ça s'arrose, un Xivd qui respecte une taille ........

mauvaise


enfin, je précise quand même : 707 Mo demandés pour avoir 702. Comme d'hab' avec le XviD 1.0 quoi...

quoi mauvaise?

Ca enduit d'erreur ton post là

Oui, mais ce n'est pas si catastrophique que cela

Et y'as aucun de vous qui a essayé d'encoder en Xvid via ffdshow ?

mauvaise (langue)

depuis que Ripp-it encode en XviD on a toujours demandé 707 Mo pour avoir 702 Mo (avec un son 128k). C'est dans ce sens qu'il respecte la taille...

oui heu c'est moyen par rapport au xvid habituel
mais je n'ai fait qu'un petit test avec les paramètres par défaut (built-in), peut-être qu'avec des règlages affinés

PS le trellis me fait des misères sur cette version xvid beta
trellis avec 2 undersize
trellis avec 1 oversize
heu sans pour la beta...

PS² je pense plutôt approfondir le ffdshow xvid....
beaucoup plus de règlages marrants...

beta testée avec trellis... 2 x 702Mo comme attendus donc... Ce n'est peut-être pas (que) le trellis qui est en cause.

Compressibilité peut être ? .....

Au fait : Avec cette version de RIAM si vous avez au résultat du test de compressibilité en XviD -/+ 50% c'est correct (pas eu le temps d'affiner plus).

Avec cette version de RIAM, le script avs impactera le résultat

Ne me demandez pas pour les autres codecs, je ne sais pas....Désolé

en apparte
dans cette version (3.10 , le divx (5.2.1pro) 1 pass sur 3 encodages de clips de 10 min = 30 min -> précision à 1 mo (merci pepsi)
avec méthode iq proche de 0.18

J'ai encensé la beta trop vite : nouvel undersize : 520 Mo au lieu de 700, film en partie sombre...

Je vais essayer sans le trellis pour vouère...

Faites des tests de compressibilité....

j'ais fais un test sur un film, le résultat était ridicule, 17%, je l'ais refait en doublant la taille du fichier, j'ais eu 102%, c'est normal comme résultats ?

Oui, le résultat des tests n'est jamais linéaire....ca serait trop simple

EDIT : Ah si, il est linéaire dans le cas d'une modification de resize

Je sais que je me répète et je comprends que vous n'ayez pas trop d'alternative, mais franchement, que d'énergie gastpillée avec ce Xvid .... c'est sidérant

J'ai cru au début, comme toi, que c'était une contrainte supplémentaire. Je ne vois plus les choses ainsi, c'est véritablement un outil pour améliorer les encodages. 2 cas réels en ce moment :

1er script


2ème script


Jamais au préalable je ne faisais varier mes resizes ainsi (dimensions + filtre), maintenant oui. Pour info le premier script, il s'agissait de faire tenir un film de 2h20 sur 1 CD de 800Mo et pour le second un manga japonais de 1h10 sur un CD de 700Mo.

Je pense avoir optimiser au mieux (les undersizes c'est fini) et je rempli au maxi les CDs en choisissant la qualité maxi que je peux obtenir.

Maintenant ça me demande 1/2h de boulot supplémentaire (+ le temps machine) pour trouver le bon script, mais je n'encode qu'une seule fois....

Les platines de salon nous limitent actuellement. Ceci étant ça bouge énormément en ce moment, de nouvelles platines arrivent avec de nouveaux supports....ça promet de belles releases pour RIAM ça...

eh je savais bien que le filtre seul ne fairait pas tout
(dimensions + filtre) l'IQ c'est aussi la compressibilité d'où baisse de la résolution...
Je ne me suis jamais penché sur les filtres (bilinear par défaut) vu que ça fausse mes calculs sauf si j'ai du temps -> HybridFupp
Et comme je suis paresseux quand ça marche pas je repasse dès foisau divx : il ne faut pas être plus royaliste que le roi

PS pour ça qu'en dehors de mes essais j'utilise les paramètres par défaut...

Tiens au fait, et sans aucun rapport, je cherche un filtre pour rajouter du "bruit" sur une vidéo, un filtre "noise" ou du style. je n'ai trouvé aucun filtre pour faire ça. Si tu as ça sous la main

Et que gagnes tu de repasser au DivX ? Certes tu va remplir le CD, oui mais le remplir de quoi ?

Pour rajouter du "bruit" il suffit de prendre un filtre de type "Sharp" non ?

non ... si c'était aussi simple, je n'aurais pas demandé .......

je me disais aussi....ben ça va pas être simple, car c'est plutôt l'effet inverse que recherche les utilisateurs.

quand tu lis sur platine et que nu n'as le choix qu'entre DivX et XviD, que le XviD est tjrs supérieur dans tous les cas de figure, et que la dernière beta permet de limiter les pics de débit, il vaut mieux l'apprivoiser... D'autant que gagner en qualité (quant 1, resize Lanczos, etc.) pour remplir le CD là où le paramétrage basique fait de l'undersize parce que le film est très compressible et que le XviD s'en sort très bien, c'est tjrs bon à prendre. Ce qui est dommage, c'est qu'à chaque fois les betas sont bcp + sensibles aux over/undersizes que les versions stables.

Pour rajouter du bruit, ya toujours au niveau du décodage, XviD, DivX et VP6 propose un "film effect", sinon tu peux essayer sous ffdshow.
A l'encodage : Un plugin de Virtual Dub. Un autre pour avisynth 2.5.X (addgrain)

Sinon, le rapport Bits/Pixel est indépendant du test de compressibilité. Et pour un meme rapport, autant on peut avoir un film mauvais ou réussi. Par exemple entre Panic Room et Robocop 2. La formule ne prends en compte que la taille de la video [bits] / (pixel d'une frame x nombre de frame de la video). Pas d'autres parametres.

Le taux de compressibilité est plus pertinent. Par contre, quelle est le nombre de frames ? prise au hasard ? Avec le script que l'on a choisi ?

EDIT : Oups, pas vu ca, dernier paragraphe. En fait je voulais dire que seul, ce rapport bits/(pixels*frames) n'est pas un indicateur.

RIAM prend 14 frames toutes les X frames. X étant fonction du pourcentage d'encodage de la vidéo (par défaut je crois que c'est 5%)

Donc :
- Test de compressibilité à 5% : Analyse de 14 frames toutes les 280 frames
- Test de compressibilité à 10% : Analyse de 14 frames toutes les 140 frames

Ah ben voilà ce qu'il me fallait "addgrain", merci CastorTroy

suite des tests de la beta 1.1 avec des films sombres et compressibles, et script tout simple



q2 avec treillis : 521 Mo
q2 sans treillis : 534 Mo
q1 sans treillis : 782 Mo
dont 92 Mo de son

au final, dans VDM : 3/4 de l'encodage en quant 1 + 1/4 de l'encodage en quant 2 = 702 Mo...
Quand il y a le choix entre over et undersize malgré des scripts Lanczos et sharp, c'est la méthode la moins prise tête que j'ai trouvée pour rentrer 702 Mo sur un CD en conservant au max la qualité et en utilisant le .pass initial pour le second encodage en quant 1 (je ne sais pas si c'est très orthodoxe, mais je n'ai jamais vu de défauts) = 3 passes en tout.

J'ai pas compris Tu veux dire faire un encodage 2 pass avec des min quant a 1 ? Pourquoi 3 pass ?

J'ai encore été trop rapide. Alors, au ralenti :

j'encode un film qui a l'air sombre et dont la beta XviD 1.1 pourrait me faire un undersize, donc je fais un script plutôt haute qualité et sharp : Lanczos ou HFupp "very high", resize élevé, pas de dénoiseur,...

(comme je n'ai pas trouvé ARCalculator je ne peux pas faire le test de compressibilité 100% fiable conseillé par Stryke)

encodage en quant 2 (2 passes) : m**** : un undersize !

alors, avec VDM, en chargeant le fichier LOG de ripp-it et l'audio déjà créée, je fais une 2nde passe en changeant juste les mini quant du XviD (= à 1), en me servant donc du fichier .pass créé lors de la 1ère passe tout à l'heure [c'est là que je ne sais pas si c'est orthodoxe de faire une 2nde passe en changeant les quant, mais je n'ai jamais vus de défauts...] = 3ème passe.

et là : re-m**** : un oversize !

alors, je prends tout simplement le début de l'AVI encodé en quant1 et je lui colle la fin de l'encodage en quant2. Le plus souvent ça fait 3/4 du film en quant1 et 1/4 en quant 2 (j'ai svt un oversize de 800 Mo et undersize de 400/500 Mo pour 700 demandés). En regardant le poids de la vidéo en bas à droite de la fenêtre de VDM, tu peux facilement couper tes 2 AVi et les recoller pour tomber à 700 Mo.

Dans le cas évoqué + haut j'ai pris presque 600Mo à l'AVI en quant 1 et un peu plus de 100 Mo à l'AVI en quant 2 pour tomber à 719100 Ko = 702 Mo.
Quant tu regardes les 2 AVI, de ttes façons, la différence de qualité est imperceptible, l'image étant à peine à peine à peine plus nette en quant1...

Voilà la version utilisée dans le tuto ICI

merci

J'ai effectivement pas précisé : je parle des cas d'oversize
donc de le mettre dans la galette
(pas taper, pas taper....)

PS je teste le ffdshow xvid, c'est bien sympa mais pas beaucoup documenté, tout à fond ça donne de bons résultats mais c'est plus long que xvid façon vp6
sinon le libavcodec (ffdshow) respecte très bien la taille.

Jamais essayé l'encodeur de ffdshow, mais je pense que ce post devrait vous aider : http://www.unite-video.com/phpbb/viewtopic.php?t=5561

le xvid ne peut plus être encodé avec les dernières versions de ffdshow ....

Avec les dernières ffdshow dans ripp-it on pourrait faire du mpeg4 (libavcodec) ?


merci Stryke
quand je ne sais plus faire en xvid je vais me pencher sur ffdshow
qui je le répète, respecte la taille finale