[ XviD ] Description des options du XviD (MAJ 25/11/2002)
Description des options du XviD (MAJ 25/11/2002) [ XviD ] - Traitement Vidéo - Video & Son
Marsh Posté le 22-11-2002 à 19:15:20
drapeau bleu
(et, sans meme avoir lu, mais je pense pas me tromper : ![[:plat00n]](https://forum-images.hardware.fr/images/perso/plat00n.gif "[:plat00n]")
)
Marsh Posté le 22-11-2002 à 19:17:18
j'utilise encore la build du 04/10/2002.
(Avant d'utiliser les versions -toujours instables- avec QPel et B-frames, je veux attendre confirmation de leur efficacité)
pour les options communes, le guide reste inchangé ?
Marsh Posté le 22-11-2002 à 19:19:16
Oui oui pas de problème. 
Sinon faudra que j'améliore certains bouts surement.
Marsh Posté le 22-11-2002 à 19:20:56
![[:the real pinzo]](https://forum-images.hardware.fr/images/perso/the real pinzo.gif "[:the real pinzo]")
Rien à redire 
J'imprimerais et lirais cela à tête reposée. Super boulot, comme d'hab. Désolé tout de même de pas pouvoir apporter une note critique, ni même une simple remarque - ce qui fait toujours davantage plaisir qu'un concert de louange 
Un ptit pdf ?
Marsh Posté le 22-11-2002 à 19:23:35
GuRu : Sans problème je te ferai un petit PDF, mais une fois que j'en serai arriver à une version quasi finale, là j'ai mis ça en ligne comme point de départ (j'ai trimé pour arriver à ce point de départ quand même)! Je vais détailler tout ça et rajouter des conseils de réglages.
Sinon merci pour les compliments!
Marsh Posté le 22-11-2002 à 19:30:11
sinon, Homie, quand tu auras peaufiné,
pourrais-tu indiquer pour chaque parametre une valeur conseillée (en réalité plusieurs, en fonction du "type" de la séquence à encoder),
ou si tu trouves ça absurde et fastidieux (à raison, chaque film étant différent) :
des indications du genre "tel param à coupler/ou non avec tel ou tel autre param",quels sont les effets d'une valeur haute, les effets d'une valeur basse, quels parametres peuvent annuler/renforcer l'effet d'un autre.
on pourrait aussi indiquer brievement quelques "stratégies" grossieres d'encodage :
par exemple, en SBC, il y a des parametres pouvant tirer la taille vers le haut (gauge/DRF/antishit) : on pouvait donner a nandub le bitrate désiré, et mettre des valeurs modérées, ou bien lui donner un bitrate excessivement bas, et mettre l'antishit à fond, etc.
ou bien pour les génériques de fin, conseiller les KF toutes les 1 sec (testé et approuvé, limite les 'trainées' de texte sur fond noir à tres bas bitrate) ... 'fin bref je pense que tu comprends ce que je veux dire.
en tout cas :
Message édité par drkarma le 22-11-2002 à 19:33:45
Marsh Posté le 22-11-2002 à 19:33:01
perso, je conseille également, pour les scenes d'obscurité qui sont bruitées (la plupart des scenes d'obscurité en fait), ainsi que pour les plans sous-marins, d'encoder la séquence à part avec des quantizers fixés à 1 :
ça fait un gros fichier, mais donne un résultat identique au DVD, et donc annihile les effets de 'sables mouvants' qui sont inévitables avec un quantizer a 2 ou +
(j'espere que j'arrive a me faire comprendre)
Message édité par drkarma le 22-11-2002 à 19:34:02
Marsh Posté le 22-11-2002 à 19:59:15
drkarma : Oui les conseils sur les réglages sont prévus! Le seul problème c'est que certaines fonctions sont pour l'instant en développement (QPel, GMC par exemple) donc je sais pas si j'attendrai fin décembre pour mettre CES FONCTIONS LA à jour ou si je mets des conseils temporaires...
Marsh Posté le 22-11-2002 à 19:59:58
kobaia : Tous les conseils sont les bienvenus! Merci d'avance.
Marsh Posté le 22-11-2002 à 20:01:23
| HomiE FR a écrit a écrit : drkarma : Oui les conseils sur les réglages sont prévus! Le seul problème c'est que certaines fonctions sont pour l'instant en développement (QPel, GMC par exemple) donc je sais pas si j'attendrai fin décembre pour mettre CES FONCTIONS LA à jour ou si je mets des conseils temporaires... |
pour les params en développement, ça me parait évident.
je parlais de ceux qui sont bien installés.
Marsh Posté le 23-11-2002 à 17:31:57
Ce qui est sur kobaia, c'est que là le XviD c'est pas lui qui gère c'est toi. Et je pense sincèrement que sur certains paramètres comme le max bitrate tu y vas un peu comme un bourrin (pas d'offense 
) et que ça handicape le codec plus qu'autre. En mettant des paramètres plus "raisonnables" :
1. Je n'ai jamais eu d'oversize ou undersize de plus de 500ko, alors que le DivX fait quasiment tout le temps des erreurs de 2 Mo voir plus.
2. J'ai quand même fait un rip LOTR avec tous tes filtres, dont un filtre de sharp si je me souviens bien, et je n'ai pas eu d'erreur du codec sur la taille finale -> c'est moi qui ait niqué le rip en n'activant la gestion du générique qu'à la seconde passe...
Là tu me donnes vraiment envie de te prendre en défaut sur ce que tu dis. Je vais bosser là dessus! Et je pense vraiment que tu as utilisé certains paramètres comme un barbare (genre les quant min/max, le max bitrate, je farfouille pour trouver des descriptions plus précises qui me permettraient de donner du "poids" à mon argumentation) -> comme le DivX est "newbie compliant" et se fout totalement de ce que tu lui rentres, ca marche toujours, mais le XviD il faut être un peu plus doux avec lui, les claques dans la gueule il aime pas ça!
A+ Je suis vraiment à la bourre pour LOTR je m'en excuse encore 
Message édité par HomiE FR le 23-11-2002 à 17:32:36
Marsh Posté le 23-11-2002 à 19:44:00
Bah oui pour les paramètres c'est aux Qmini/maxi que je pense par exemple, mais aussi le célèbre Max bitrate que tu mets au bitrate moyen. Je sais pas ça fait tache! (mais bon c'est juste mon avis)
Pour LOTR je compte lancer la 1ère passe ce soir, et demain matin la seconde, comme ça demain soir dernier delai c'est fini (XP 2000+ ça doit aller quand même). Pour les filtres je sais pas encore si je les mets, ou si je mets juste un petit Conv3D (movieHQ) pour smoother un poil la source (qui est déjà vraiment nickel). Pour les paramètres, je resterai plus sobre que toi (mais quand même des B-frames, pas de QPel ni GMC). Et comme curve compression, je pense prendre une compression linéaire, même si ça m'inquiète un peu pour certains passages, donc peut être une Alt Curve réglée pour le film (param choisis en fonction de la 1ère passe pour se donner bonne conscience). J'aimerais bien le faire moi même maintenant que tu as "descendu" le XviD comme ça! Si tu me dis que ça pue et bin voilà je serai fixé, mais je préfère le faire moi-même. En plus j'avais dit que je le ferai donc je le ferai!
Dis moi ce que t'en penses.
![[:kimouss]](https://forum-images.hardware.fr/images/perso/kimouss.gif "[:kimouss]")
Marsh Posté le 24-11-2002 à 09:45:02
OK la deuxième passe est lancée. Je prépare un petit post récapitulatif de ce rip avec toutes les infos nécessaires :
1. réglages complets du XviD
2. Script AVS utilisé (aucun filtrage!)
3. Informations importantes première passe
4. Informations importantes fichier final
Ca devrait arriver en début d'après midi. Et je parie dès à présent qu'avec les réglages que j'ai fait, il n'y aura pas d'oversize ni d'undersize du tout!
D'ailleurs j'ai utilisé l'alt-curve ici donc pas de payback delay ni tout ce qu'il y a dans le cadre curve compression de l'onglet Two Pass. Quand on active l'alt-curve, tout ce cadre est désactivé. C'est d'ailleurs pour ça que je pense que les paramètres Max bitrate, Overflow improvement et degradation ne sont pas directement liés au payback delay, puisque par exemple dans mon rip le payback delay est désavtivé, alors que la gestion du max bitrate et des overflows est toujours activée d'après ce que disent les développeurs du XviD.
A++
Marsh Posté le 24-11-2002 à 15:22:30
| kobaia a écrit a écrit : pour revenir sur le petit comparo LOTR @600k entre XviD et DivX |
>> XviD paramétrage bas débit
vos discussions sont tres interessantes mais ce topic concerne aussi les moyens et haut débit je pense
Marsh Posté le 24-11-2002 à 16:14:28
Du calme kobaia il n'y a pas lieu de s'énerver pour si peu. Enfin je crois. Déjà, je crois pas changer d'optique en disant que j'utilise l'alt curve.
Petite explication rapide du fonctionnement du curve compression dans le XviD :
Il y a 3 façons de gérer cette compression de courbe :
1. Une "compression" linéaire (on peut quasiment pas parler de compression je trouve) en fait on multiplie par un scalaire la courbe de bitrates de la première passe et on fait tout au niveau quantificateur pour s'y tenir au plus près. Cette compression linéaire ne se fait pour moi (a priori) pile poil, étant donné que le codec ne peut savoir a priori combien fera une frame avec un quantificateur qu'il n'a pas encore essayé. Après je suis pas surper calé (désolé j'ai pas encore trouvé où apprendre le mécanisme exact), mais je pense que le codec essaie de se rapprocher le plus de la valeur nécessaire. Il y a toujours une erreur, positive ou négative, qui va rester s'additionner avec les erreurs précédentes pour donner un petit paquet de bits qu'on appelle overflow. A chaque image, le codec essaie (selon moi) d'atteindre comme taille la taille de la frame multipliée par le scalaire de compression linéaire plus la taille de l'overflow (positif ou négatif). Dans une compression linéaire, le codec réagit comme ça tout connement sans regarder les tailles de frames par rapport à la taille moyenne ou autre, comme le temps passé par des bits dans l'overflow.
EUH! Là je dois quand même préciser que pour moi il tient compte du paramètre max bitrate (que je ne connais pas bien en effet mais vu que je le laisse à 10000 ça pose pas de problème c'est comme si il n'avait pas d'effet) et des max overflow improvement/degradation. Imaginons que le max bitrate corresponde à un bitrate instantané maximum (je sais que tes tests ne vont pas dans ce sens, mais les réglages ultra tendus que tu avais fait ici et par ailleurs avaient peut être enrayés toute la machine -> je sais c'est pas bien que le codec soit pas capable de se débrouiller quand on le tire très fort, mais bon voir la fin du post si j'oublie pas d'ici là). Dans ce cas le codec fait gaffe au moment de compresser une frame que le bitrate instantané (taille frame / durée frame=1/25 s) ne dépasse pas cette valeur. De plus il fait aussi gaffe que l'overflow ne se remplisse ou ne se vide pas trop vite grace aux paramètres max overflow improvement/degradation.
2. La curve compression (le petit cadre dans l'onglet Two Pass, avec ton très cher Payback Delay). Dans ce cas, il y a toujours une compression linéaire au départ, mais on y ajoute des petits tweaks qui permettent de répartir les bits de l'overflow plus intelligemment :
- déjà le codec fait la différence entre les frames de petites tailles et les frames de grandes tailles et réagit différemment pour chaquee type de frames (high et low bitrates). Ici si les frames sont plus petites que la moyenne, il leur rajoute des bits qu'il aura pris aux grosses frames, un peu à la manière d'un robin des bois en fait. Mais là je vois bien un petit problème : si tu fous 0 pour high et 100 pour low, ça risque de couiller grâve parce que tu fous toutes les frames trop petites à la taille moyenne -> boost de taille, sans prendre aucun bit aux grosses frames. A mon avis dans ce cas le codec doit utiliser (ou devrait utiliser j'en sais rien j'ai pas vu le code) un algo de secours qui va prendre à toutes les frames des bits de façon à faire que les bits "négatifs" dans l'overflow n'y restent pas plus longtemps que le payback delay! M'enfin c'est la seule solution que j'imagine comme possible pour que le codec s'en sorte -> sinon c'est oversize direct!
- avec le payback delay, le codec stocke aussi pour chaque bit de l'overflow (?!) le temps depuis lequel il se trouve là, et le force à être utilisé avant de dépaser la valeur de temps en frames définie par le payback delay.
3. L'alternative curve compression.
JE SUIS SUR QUE DANS CE CAS LE CADRE CURVE COMPRESSION EST DESACTIVE !(je mets pas de maj pour gueuler, juste pour le signaler, je vais quans même vérifier pour pas passer pour un débile, ce qui est possible). Je mettrai le lien vers Doom9 quand j'aurai trouvé, mais je suis vraiment sur (j'espère ne pas me tromper sur ce coup, sinon ça fout tout mon post par terre) que j'ai lu ca de la bouche d'un developpeur... Je croise les doigts et je continue quand même parce que de toute façon mon truc tient debout et je le trouve plus "logique" que de faire intervenir uniquement la payback delay alors que les autres options du cadre curve compression sont désactivés -> ils auraient sorti/ dû sortir cette option du cadre!
Bon l'alt curve rajoute d'autres tweaks que dans le cas 2. Ici on raisonne en terme de taille de frame par rapport à la taille moyenne d'une frame obtenue après compression linéaire. Déjà les param High Distance et Low Distance définissent les tailles relatives min et max de frames (juste après la compression linéaires) en dehors desquelles on va fouttre :
- dans le premier cas la qualité relative minimum définie en dessous automatiquement ou manuellement,
- dans le second cas un qualité maximum -> quant = 2 à coup sur.
Ensuite l'agression va permettre de jouer sur la "FORCE" de la compression appliquée : si tu mets Low, la courbe va ressembler encore à une ligne d'horizon montagneuse (genre les alpes) où t'auras des grandes variations de bitrate (mais de toute façon moins que la high distance + low distance d'après ce qui précède, car on fait de toute façon une compression de courbe pas une amplification des variations de la courbe). Si tu mets Medium, la ligne d'horizon sera plus applatie (genre le massif central) et si tu mets High ca va être tout plat plat et rester proche du bitrate moyen. Là je raconte ça comme un con, mais au niveau de l'algorithme le codec va surement adapter son coefficient lineaire de compression en fonction de la distance de la frame considérée avec la taille moyenne d'une frame -> compression adaptative quasi inexsitante pour Low, compression ultra adaptative pour High de façon à faire tendre la bitrate vers une constante au cours du temps.
Mais mais mais là comme tu le vois je ne raisonne qu'en terme de coefficient de compression linéaire, toujours dans ma tête (comme je n'ai rien trouvé sur le sujet et que j'ai pas encore farfouillé dans le code du XviD, chose que je devrai faire de toute façon un jour ou l'autre) je suis convaincu que le codec ne peut pas savoir exactement quelle taille fera une frame avec un quant avant de l'avoir compressé avec ce quant pour tester. Donc il va y avoir des erreurs dues à la compression supplémentaire "adaptative" de l'alt-curve, qui vont donc aller dans l'overflow (encore lui). Là pour moi le payback delay est OFF, et donc la temps passé par des bits dans l'overflow n'a plus d'importance pour le codec. Il s'intéresse plutot au fait de distribuer plus ou moins de bits aux frames en fonction de leur taille relative ou de leur qualité relative. Par contre pour moi, les paramètres max bitrate et max overflow improvement et degradation ont toujours leur place, car ils permettent encore pour les deux derniers d'éviter un remplissage ou un vidage trop rapide de l'overflow (des gardes fous en somme). Pour le premier, il s'agit selon moi avant de chercher plus d'infos (je trouve pas je suis désolé), que si il est réglé en dessous du bitrate instantané de la frame "high distance" de limiter le bitrate -> évidemment dans ce cas ca fait un peu couillon d'avoir les deux paramètres ensemble mais bon je trouve que ça se tient, si on règle "judicieusement".
Mais au fait je n'ai pas parlé de bonus pour l'alt curve... En fait je pense que le bonus correspond à l'overflow quand on active l'alt-curve. C'est mon avis pour l'instant et avant preuve du contraire. Car je vois mal comment parler d'overflow et de bonus DISTINCTS dans le mécanisme d'alt curve. A confirmer donc (je précise juste que je ne suis pas développeur du XviD donc je ne connais pas tout sur ses mécanismes de fonctionnement).
Enfin pour en revenir au problème de la réactivité du codec face à des réglages "strong" à la kobaia (qui peuvent très bien se comprendre), et bien je sais pas trop quoi dire je n'ai pas encore testé mais ce qui est sur c'est que si tu es convaincu que le codec a de réels problèmes tu peux facilement poster sur le forum de xvid.org ou le forum de Doom9 section XviD pour voir ce que les développeurs répondront. Ce qui est sur c'est que le codec n'est pas souvent du tout utilisé par des testeurs comme tu le fais, donc ça pourrait peut être les aider à trouver des failles dans le code là où ils ne les attendaient pas, ou à tweaker le codec pour améliorer ses réactions.
Parce que pour ce qui est du DivX5 j'en reviens toujours à mes réticences sur son "intelligence". T'inquiète pas j'ai lu la page du site DivX.com sur les fonctions du codec, mais bon ça reste très flou je trouve et il n'y a aucun moyen de cerner vraiment ce que fait le codec. Genre comme tu le dis toi même tu rentres des quant min max à 1/3 et il fait toujours ce qu'il veut. Le truc c'est que tu sais comment faire réagir visuellement le codec à ce que tu lui demandes, mais le XviD réagit pas pareil aux mêmes paramètres car peut être qu'il essaie plus de coller à ce que tu lui demandes, mais comme il ne peut pas le faire du à d'autres limitations ailleurs dans les raglages il s'emmele les pinceaux...
Et pis pour le fait que les réglages du XviD ressemblent aux réglages du DivX5, je rigole quand même doucement en repensant à la première version du DivX4 pompant l'idée des 2 passes instaurée par Nandub POUR LE MPEG-4! Et là c'est clair qu'il y a eu un beau pompage, franc et net. D'ailleurs le Payback Delay réutilisé sous un autre nom (me souviens plus) dans le DivX, peut être un poil modifié, vient directement de Nandub, cf Nandub que je viens d'ouvrir. Voili voilou.
PS : j'espère que tu te vexes pas trop, tu sais j'ai pas d'actions chez XviD, c'est un codec open-source pas comme le DivX! 
Nan je déconne je m'en contrefous que le XviD soit meilleur ou non que le DivX (ce qui ne veut pas dire que je pense que le XviD soit derrière le DivX, loin de là), c'est juste un petit comparo c'est tout.
Message édité par HomiE FR le 24-11-2002 à 16:32:46
Marsh Posté le 24-11-2002 à 16:57:17
au fait, il y a un post qui poursuit le meme but ici : http://atlas2.tgv.net/~media-video [...] .php?t=549
Homie-> 
Marsh Posté le 24-11-2002 à 18:21:33
kobaia : j'avais TORD le payback delay semble être actif d'après ce que j'ai lu sur le forum Doom9 (quoique je n'en sois pas encore sur, donc j'ai posté pour m'en assurer)! Mais par contre ça ne change rien du tout à la comprehension que j'avais de la gestion de l'overflow auparavant.
Pour moi je considérais au dessus que le payback delay était réglé à + infini, mais en fait comme pour la curve compression classique il faut avoir un garde fou pour éviter que trop ou pas assez de bits ne reste indéfiniment dedans.
DONC TU AVAIS RAISON MAIS JE PENSE QUAND MÊME QUE CE SUR QUOI TU ME REPRENAIS N'EST PAS CLAIR. Déjà, pas besoin a priori de payback delay pour gérer la curve si les réglages sont bons, mais en fait le maillon faible de mon raisonnement c'est qu'il n'y a pas de réglage parfait donc le payback delay vient sauver la mise pourle rip qui soit se barrerait vers un oversize ou vers un undersize. Au fur et à mesure que j'écris ce post je me rends compte de l'importance de ce paramètre! Mais si tu lis ce que je dis au dessus, rien n'est faux excepté la nécessité de la prise en charge temporelle de l'overflow. Donc oui tu as raison le payback delay est indispensable, pour éviter les gros pépins, mais bon quand même les paramètres max overflow improvement/degradation et autres font quand même le gros du boulot. Le payback delay se met en action pour la petite partie des bits qui restent bloqués dans l'overflow, qui si elle n'est pas évacuée peut poser de gros problèmes d'oversize ou d'undersize (bits négatifs).
OK donc je suis finalement convaincu que le payback delay joue un role dans toute curve compression (pas la compression linéaire bien sur). Voilà, maintenant avec ce que j'ai écrit là dessus je vais pouvoir faire une explication détaillée de la façon dont fonctionnent les curve compressions du XviD.
Marsh Posté le 24-11-2002 à 18:25:31
Dernière précision : j'avais bien lu que tout le cadre curve compression était désactivé, mais pas de la bouche d'un développeur hélas!
Malgré tout, c'est vraiment mal foutu à ce niveau là parce que ça laisse vraiment penser que le payback delay est désactivé (sauf si on s'appelle kobaia). Franchement il devrait sortir ce paramètre du cadre, ça augmenterait franchement la lisibilité, en ajoutant aussi un "standard" devant curve compression pour faire la distinction avec l'alt-curve.
Marsh Posté le 24-11-2002 à 19:01:32
Kobaia:
J'ai vu que t'utilisait les quant mpeg pour tes encodages.
Si tu trouve que c'est pas terrible, essaye avec du h263.(surtout pour du 600k).Ca sera surement un peu plus flou mais bon ça fait gagner a peu près 4% en compressibilité généralement.
Pour des debits aussi bas y a meme pas de question a se poser normalement, c'est h263 a tout les coup.
Marsh Posté le 24-11-2002 à 19:05:12
OK bah tu pourras voir comment je me "rattrape" aux branches vers la fin... Je pense que j'avais compris le fonctionnement, EXCEPTE QUE je n'avais pas estimé l'importance du payback delay à sa juste valeur (comme les rillettes Bordeaux Chesnel© en somme, "nous n'avions pas les mêmes valeurs" ).
Bon finalement je me suis assez facilement convaincu en imaginant "abstraitement" le fontionnement du truc que sans limite temporelle pour l'overflow, ça part au bout d'un certain temps en vrille -> oversize ou undersize en fonction des réglages entrés. Mais je vais faire des tests pratiques sur 10000 frames pour me convaincre totalement.
Sinon pour le rip LOTR j'ai encore foiré mon coup parce que la gestion des credits avec les B-frames n'a pas l'air au point (ou alors cette version a un GROS problème avec le respect de la taille entrée -> chose qui n'existait pas sur les versions précédentes puisque j'ai fait un Panic Room nickel avec moins de 200 Ko d'undersize sur 1CD). J'en suis à la deuxième passe d'un nouveau rip sans la gestion des credits, toujours sans filtrage -> 3h20 pour une passe.
Je poste les résultats quand c'est fini!
Marsh Posté le 25-11-2002 à 14:57:07
Bravo !
C'est juste ce qu'il me manquait pour passer au Xvid
Marsh Posté le 25-11-2002 à 17:02:21
![[:drapo]](https://forum-images.hardware.fr/images/perso/drapo.gif "[:drapo]")
---------------
Date d'arrivée sur le forum: le 2-02-2000
Marsh Posté le 25-11-2002 à 19:49:23
M'en vais mettre à jour le descriptif dès que j'ai fini -> le coup de l'unité de temps fait tache, même si j'ai toujours qu'une vision "personelle" de la chose (pas moyen de trouver des infos sur Doom9 hélas, je vais devoir poster et tout et tout).
Sinon au niveau du "vocabulaire" pour moi l'overflow c'est le "réservoir" de bits (valeur positive ou négative ie bits en trop ou en moins), et donc j'ai du mal à faire la distinction avec le bonus, qui correspond aussi pour moi au "réservoir" de bits... Excepté que d'après les descriptions le bonus correspond uniquement aux bits pris aux grosses frames (donc que positif) EN PLUS grâce à l'alternative curve compression.
Au départ je me disais que lors de l'utilisation de l'alternative curve compression, le codec ne faisait même pas référence au "linear scaling" de la courbe, qui lui sert quand même de point de départ. Mais en fait, peut être que le codec stocke quand même temporairement au moment de compresser une frame :
- le quant qu'il aurait utilisé sans utilisation de cette compression adaptative qu'est l'alt curve,
- le quant réellement utilisé après compression adaptative.
Dans ce cas l'overflow serait encore l'erreur faite par le codec au moment de l'estimation de la taille de la frame avec le quantificateur effectivement appliqué.
Et le bonus corresponderait à la différence théorique (je pense pas que le codec compresse réellement l'image deux fois, m'enfin je suis pas trop sur) entre les tailles de la frame compressée aux deux quantificateurs différents.
Cette explication me conviendrait assez bien, je vois d'endroit ou le raisonnement cloche, mais faut quand même regarder le code en détail pour voir si ca fait bien ça, ou avoir accès à tous ces réservoirs au cours de l'encodage pour vérifier...
Et pour les max overflow improvement/degradation je pense que tu es dans le vrai : je me suis un peu emporté en disant qu'ils faisaient le gros du boulot, ils sont plutot là en fait pour faire (encore une fois désolé) les gardes fous du payback delay. La vache j'avais vraiment pas réalisé à quel point ce paramètre était important! C'est vraiment lui qui peut te fouttre en l'air un encodage...
Merci kobaia pour m'avoir éclairé sur ce point.
Là je viens de faire un bug report au niveau de l'alt curve que ne gérait pas correctement les B-frames : mes rips undersizés étaient dûs à l'alt curve! Foxer m'a dit qu'il avait réglé le bug. Reste plus qu'à attendre une nouvelle version de Koepi... J'aimerais bien finir sur une version vraiment nickelle avec tout ce que je veux mais j'ai déjà une version standard cc avec une taille parfaite et des b-frames (c'est tout, pas de qpel).
En ce moment je refais une version standard cc, mais avec un nouveau lumi masking sensé ne plus dégrader l'image et le qpel pour voir l'effet.
Marsh Posté le 25-11-2002 à 19:57:52
A un nouveau post pendant que je tappais!
Pour le max je suis content en effet, mais bon c'est à confirmer. Ensuite je vais faire quelque chose de très barbare, à savoir traduire une gros bout des posts précédents en anglais et les poster sur Doom9 pour voir si je suis dans le vrai, et si c'est pas le cas, ou est le maillon faible.
Parce que de toute façon une curve compression telle que je l'ai décrite fonctionne selon moi. Je dis pas qu'elle produit des résultats magnifiques (loin de là) mais ce qui est sur c'est que sans infos supplémentaires elle pourrait marcher comme ça.
Je suis en effet de ton avis quand tu veux tester de fond en comble le truc, mais néanmoins il nous faudrait plus d'infos intermédiaires sur quoi nous baser pendant l'encodage. Là sans ces infos on va devoir :
- soit faire des tonnes de tests
- soit activer le pifomètre
Marsh Posté le 27-11-2002 à 22:09:31
Salut kobaia!
Je travaille d'arrache pied sur mon guide sur la compression d'un DVD en MPEG-4 (avec XviD).
Faut que je fasse un article, donc faut soigner le style etc... Et ça met du temps, surtout quand on veut le faire bien.
Sinon mon rip LOTR Lumi + QPel + B-frames(2,150,100) avec une curve compression standard est assez impressionnant. Pour rigoler, j'ai aussi rippé LOTR en RV9 avec quasiment les mêmes paramètres (sauf un filtre de sharp UnFilter pour aider le RV9 à garder un peu de détails supplémentaires). Et bin je me surprends à préférer le rip XviD, même dans ces situations supposées extremes pour le codec. Le RV9 est quand même vraiment trop flou sur certains points, et je ne pinaille pas en disant ça. La saleté de la compression est moins visible ici et moins gênante que le flou du RV9.
Cependant je ne me rejouis pas trop vite. Je sais pas pourquoi mais LOTR se compresse vraiment mieux que la moyenne des films en MPEG-4! Je vais faire mumuse ensuite sur SW EP1 (ou EP2 si je me le procure d'ici là) et ce sera peut être une autre paire de manches.
Sinon je vais t'envoyer un CD d'ici peu, mais j'attends une dernière build de Koepi corrigeant le prob d'undersize de l'alt CC pour pouvoir l'utiliser et mettre comme options B-frame(2,150,100) + Lumi + QPel + Chroma Motion.
Marsh Posté le 27-11-2002 à 22:22:10
Est-ce que tu utilises le GMC? Sinon un guide sera le bienvenu, mais il ne faut pas oublier que les dvd encodés avec la version actuelle du codec (de développement) ne pourra peut être plus êter lue par les futures versions...
Marsh Posté le 27-11-2002 à 22:25:49
Nan le GMC est trop buggé actuellement. J'ai essayé sur quelques extraits mais je n'ai vu aucun intéret à utiliser une fonction buggée qui n'apporte aucun gain visuel.
On verra plus tard pour le GMC.
Marsh Posté le 27-11-2002 à 22:28:00
Sinon si tu n'utilises pas le GMC actuellement toutes les autres options sont MPEG-4 compliant, donc de toute façon les fichiers créés seront lisibles avec tout décodeur MPEG-4 compliant. Pas de problème de ce coté là.
Marsh Posté le 27-11-2002 à 22:32:18
| HomiE FR a écrit a écrit : Sinon si tu n'utilises pas le GMC actuellement toutes les autres options sont MPEG-4 compliant, donc de toute façon les fichiers créés seront lisibles avec tout décodeur MPEG-4 compliant. Pas de problème de ce coté là. |
ok, c'était justement à propos de l'utilisation du GMC que je me posait des questions pour la perennité.
Marsh Posté le 28-11-2002 à 20:19:29
Bon bon je m'avance peut être un peu c'est vrai (tiens au fait je vais faire mumuse avec le player de MPEG4IP que j'ai downloadé il y quelques jours : on va voir ce qu'il dit de mes flux XviD avec un container MPEG-4).
Je posterai les résultats.
Sinon j'attends toujours la nouvelle build de Koepi. Si dimanche elle est pas là je t'envoie ce que j'ai.
Marsh Posté le 29-11-2002 à 17:35:46
J'ai pas tout lu.
Ca a l'air assez interessant et je suis tout a fait d'accord avec toi sur le points des quantizers.
Je sais pas si vous avez essayer d'encoder avec des quantizer fixe à 31, eh ben c'et pas chouette du tout!
Marsh Posté le 29-11-2002 à 18:13:09
Salut kobaia !
Joli post, comme à l'accoutumée. Bon je vois que tu fais du test intensif au niveau du peak -> bin tant mieux parce que j'ai pas encore demandé du coté des développeurs ce que ça faisait réellement. Enfin peut être que ce week end je vais ESSAYER de jeter un oeil aux sources C. On va voir ce que j'arrive à piger, mais je vais d'abord me focaliser sur les curve compressions et donc les paramètres genre peak et autre si j'y arrive pour voir... M'enfin je suis pas le roi du C (ni de la prog en général en fait), donc faut pas s'attendre à des miracles de ma part.
Sinon là je suis tout fou je me fais LOTR sur 700 MB (son Vorbis Q0 & vidéo XviD 517 kbps !!). J'en suis à 70% de la 2ème passe (qui va assez lentement puisque j'ai fait le pari de mettre le QPel, le Lumi Masking et le Chroma motion en plus des maintenant habituelles B-frames). On verra ce que ça donne, mais j'ai l'espoir que ce soit tout à fait regardable, sans postprocessing j'entends bien sur.
Je vais regarder pour les passages que tu cites, et je te donne la réponse dans la soirée normalement.
Pour mercredi faut que j'avance bcp mon pseudo guide, le problème étant que je le fais pour des personnes ne connaissant rien à la compression vidéo. Donc description de la compression type J/M-PEG, et guide à proprement parler en détaillant tout, ce qui prend énormément de temps...
Marsh Posté le 29-11-2002 à 19:41:21
je pose uen question déja posée en partie a homie fr : comment enregister en xvid avec un minimum de ressources, tant pis pour la taille, sachant que c'est pour de la capture télé en 756*576
en fait en 384*288, simple trame, je suis a 25% de cpu, mais si j'arrive pas a vraiement baisser ce qui bouffe du cp, c'est chaud pour le 756*576 en regland un peu qq parametres, j'arrive a un résultat ou je perd pas trop de frames, masi il me faudrait vraiement le parametrage le moisn gourmand en cpu, quitte a avoir des gros fichiers
---------------
Bitcoin, Magical Thinking, and Political Ideology
Marsh Posté le 30-11-2002 à 11:43:07
Voilà un petit lien vers un post de Doom9 sur les matrices de quantification faites maison :
http://forum.doom9.org/showthread. [...] adid=33499
Ca papote pas mal, et ils font des essais de matrices, j'ai pas encore testé mais c'est vrai que ca devrait être de ce coté là maintenant qu'il faut chercher les améliorations sensibles de qualité visuelle. Parce que bon la matrice de quantification détermine un peu les artefacts qu'on aura en sortie et leurs répartitions sur les images...
Sujets relatifs:
- video Xvid illisible quelque soit le lecteur :(
- Xvid vers SVCD NTFS -> comment faire ?
- Lire un xvid avec le codec divx. Y a t il une perte ?
- Avec quoi on lit les xvid????
- [MAJ le 18/11/02] Topic général : Jukebox MP3 Thomson Lyra PDP2800 10G
- [The Topic] Xvid
- [ffdshow] c quoi ce truc avec mes codec divix ou xvid ??
- codecs xvid ac3 et divx
- convertir un divx (xvid) en vcd
- codec XVID
Marsh Posté le 22-11-2002 à 19:04:20
Description des options du XviD
par HomiE FR (homie2003@ifrance.com)
Dernière mise à jour : 25/11/2002
Version du codec utilisée : Koepi 25-11-2002-1 ALPHA
Le XviD est un codec MPEG-4 open-source à but éducatif qui respecte la norme ISO. Il est développé et mis à jour quotidiennement par des personnes venant des 4 coins de la planète. Vous pouvez utiliser les versions compilées du codec présentes aux liens indiqués en dessous à vos risques et périls : les webmasters de ces sites ne pourront en aucun cas être tenus pour responsables de l'usage qui sera fait du codec.
Liens importants :
Ce site permet d?obtenir régulièrement des nouvelles de l?avancement du développement du codec. Il possède un forum où les développeurs principaux du codec passent régulièrement : il est donc possible de leur poser des questions (intelligentes de préférence). De plus, sa sections Links permet d?obtenir des adresses intéressantes au sujet du MPEG-4.
Ce site permet de télécharger les versions du codec XviD (encodeur + décodeur) compilées par Koepi, un membre de l?équipe de développement du codec. Deux types de versions du codec sont téléchargeables : les versions stables ne contenant que les options déjà éprouvées, et les versions alpha instables contenant des options introduites récemment dans le code, comme les B-frames, le Quarter Pixel ou encore le Global Motion Compensation. Notez que les versions du codec sont mises à jour régulièrement.
Ce site permet de télécharger les versions du codec XviD (encodeur + décodeur) compilées par Nic, le membre de l?équipe de développement du XviD qui s?occupe du décodeur. Notez que les versions du codec sont mises à jour assez épisodiquement.
Ce site permet de télécharger les versions du codec XviD (encodeur + décodeur) compilées par uManiac. La particularité de ce site réside dans la présence de versions appelées Insta Builds, c?est à dire des versions du codec provenant directement du CVS, sans aucune modification. Notez que les versions du codec sont mises à jour assez rarement.
Ce forum est l?un des forums les plus actifs en ce qui concerne la compression vidéo. Il possède un sous-forum XviD très animé, où certains développeurs du XviD sont présents (comme ?h, Koepi ou Nic par exemple). Les thèmes importants liés au codec ainsi qu?à la compression en général y sont traités, et l?ambiance y est bonne tant que la fonction Search est utilisée avant de poster un nouveau topic.
Configuration du mode d?encodage :
Encoding Mode :
L?encodage se fait en 1 passe, en respectant le mieux possible le débit entré dans la case Bitrate (de 0 à 10000 kbps). Notez que le terme CBR est utilisé abusivement : le codec n?est CBR qu?en comparaison avec les autres modes d?encodage. Une compression MPEG-4 ne peut en effet tout simplement pas se faire avec un bitrate constant au cours du temps, du fait du principe même de la quantification.
L?encodage se fait en 1 passe, en essayant de respecter une qualité visuelle constante tout au long du film entrée dans la case Quality (de 0 à 100). Notez que selon les développeurs du codec, ce mode fait appel à des algorithmes assez complexe d'estimation de mouvement pour tenter d'arriver à ses fins.
L?encodage se fait en 1 passe, en utilisant un quantificateur constant pendant tout le film (de 1 à 31). Notez que le quantificateur 1 ne compresse pas les données : la compression MPEG-4 la plus faible correspond à un quantificateur constant égal à 2. Attention : un quantificateur constant ne signifie pas un bitrate constant mais plutôt un taux de compression constant.
L?encodage se fait en 2 passes : ce mode permet d?effectuer la 1ère passe, qui encode le film avec un quantificateur fixé à 2 sans produire de fichier en sortie et crée un fichier d?informations de type .STATS qui sera réutilisé par le codec pour la seconde passe. Ce fichier contient la taille de toutes les frames compressées, le niveau de mouvement de chaque frame, ainsi que la position des I-frames, P-frames et B-frames.
L?encodage se fait en 2 passes : ce mode permet d?effectuer la 2de passe, en utilisant un fichier .STATS modifié avec un programme extérieur, imposant au codec pour chaque frame les options de compression. Dans ce mode, le codec n'est plus maitre de la compression : veillez donc à paramétrer correctement le programme utilisé pour modifier le fichier .STATS !
L?encodage se fait en 2 passes : ce mode permet d?effectuer la 2de passe, en utilisant un fichier .STATS créé pendant la 1ère passe par le codec, sans modification ultérieure. La taille finale du fichier vidéo doit être entrée dans la case Desired size (en KBytes). Au contraire du mode d'encodage précédent, celui-ci prend en compte les différents réglages du codec. Attention : les réglages de l'onglet Global et de l'onglet Credits doivent être les mêmes pendant la 1ère et la 2de passe !
Il n?y a pas de réel encodage : ce mode permet de tester la vitesse d?un encodage futur avec les paramètres choisis dans le codec. Ce mode n'a pas de réel utilité, sauf dans le cas de tests de vitesse de compression en utilisant une machine dont l'espace disque est très limité (cas rarissime donc).
Ce bouton permet d?accéder à l?ensemble des réglages avancés détaillés dans la suite de ce descriptif : choix du type de quantification, de la précision de l?algorithme de détection de mouvement, réglage des B-frames, de l?algorithme de compression de courbe de bitrates en mode 2 passes, de la gestion du générique de fin?
Ce bouton permet à tout moment d?utiliser les réglages par défaut du codec. Notez que ces réglages ont été choisis par les développeurs du codec comme étant adaptés à la grande majorité des situations, n'ayez donc pas peur de vous en servir soit tels quels, soit comme base pour paramétrer le codec.
Configuration de l?onglet Global :
Global settings :
Cette case permet de régler la précision du détecteur de mouvement interne (de 0 à 6). Notez que la précision 0 désactive totalement la détection de mouvement pendant la compression, ce qui est hautement déconseillé. Une précision de 6 - Ultra High est conseillée dans toutes les situations possibles.
Cette case permet de choisir le type de quantification utilisé, c?est à dire la matrice de quantification utilisée pour compresser chaque bloc de chaque frame compressée par le codec, une fois la DCT (Discrete Cosinus Transform) appliquée. La matrice de quantification correspond à la compression de référence d?un bloc, les quantificateurs permettant par la suite de moduler cette compression.
Ce type de quantification produit un léger flou sur l?image, mais aucun grain visible. Il est particulièrement adapté pour des bitrates inférieurs à 900 kbps, mais peut convenir à la grande majorité des situations.
Ce type de quantification produit une image plus nette que le précédent, mais aussi le grain caractéristique de la compression MPEG. Il convient bien aux bitrates supérieurs à 900 kbps.
Ce type de quantification permet à l?utilisateur de choisir lui-même la matrice de quantification à utiliser via l?onglet Quantization. Notez que l?utilisation d?un tel type de quantification produit néanmoins un fichier vidéo tout à fait valide quant aux normes du format MPEG-4.
Ce type de quantification utilise le type MPEG pour les frames compressées avec des quantificateurs 2 et 3, et le type H263 pour les frames compressées avec des quantificateurs supérieurs à 3. Il permet d'obtenir un très bon niveau de détail aux faibles quantificateurs, tout en évitant un grain trop visible.
Ce type de quantification utilise le type H263 pour les frames compressées avec des quantificateurs 2 et 3, et le type MPEG pour les frames compressées avec des quantificateurs supérieurs à 3. Il permet d'obtenir un très bon niveau de détail sur l'ensemble du film, tout en évitant un floutage trop appuyé.
Cette case permet de choisir le FourCC inscrit dans le fichier vidéo, c?est à dire comment il est identifié et donc décodé. Un FourCC XVID entraîne un décodage par un décodeur XviD, tandis qu?un FourCC DIVX ou DX50 entraîne un décodage par un décodeur DivX. Un FourCC XVID est conseillé pour lire un fichier compressé avec le codec XviD, mais un FourCC DIVX ou DX50 ne posera pas de problème non plus.
Cette case permet de régler l?intervalle maximum (en frames) autorisé entre 2 I-frames. Ce paramètre permet donc de forcer le codec à insérer une I-frame après la durée indiquée afin d'éviter une dégradation sensible de l'image dûe justement à la pénurie de I-frames, frames de "référence" dans le fichier vidéo.
Cette case permet de régler l?intervalle minimum autorisé entre 2 I-frames. Un intervalle minimum réglé à 1 autorise les I-frames consécutives. Ce réglage permet alors théoriquement au codec de placer plusieurs I-frames consécutives quand l'image varie énormément d'une frame sur l'autre : l'utilisation de P-frames devient obsolète étant donné que celles-ci contiendraient quasiment tous les blocs de l'image.
Cette case permet d?activer le lumi masking, mécanisme qui compresse plus fortement les zones très claires et très sombres sans que leur qualité visuelle n?en soit théoriquement affectée. Notez que la détection de telles zones se fait uniquement sur la luminance. Attention : ce paramètre permet d'augmenter sensiblement la compressibilité de la source, mais au prix d'artefacts parfois assez gênants !
Cette case permet d?activer la gestion de sources entrelacées directement par le codec.
Cette case permet d?activer le mode Quarter Pixel (ou QPel) : ce mode divise virtuellement chaque bloc de la source en 4, afin d?obtenir une estimation du mouvement plus précise puisque le déplacement minimum d?un bloc sur 2 frames consécutives est ainsi divisé par 4. Notez que, si cette fonction n?est pas activée, le codec utilise quand même le mode Half Pixel qui correspond à une division virtuelle de chaque bloc par 2 au moment de l?estimation de mouvement. Attention : cette option est en cours de développement !
Cette case permet d?encoder le film en noir et blanc : le codec ne tient alors plus compte des informations sur la chrominance pour ne compresser que les informations sur la luminance, d'où un gain de place consistant à résolution et quantificateur constants. Attention : les informations sur la couleur sont alors perdues !
Cette case permet d?utiliser les informations sur la chrominance au lieu des informations sur la luminance seulement pour détecter le mouvement, rendant la détection plus sûre, puisque le codec peut se baser sur 2 matrices de données (chrominance bleue et chrominance rouge) au lieu d'une pour estimer le mouvement. Attention : cette option est en cours de développement et ralentit considérablement l'encodage !
Cette case permet d?activer le mode Global Motion Compensation (ou GMC) : il améliore la gestion des scènes contenant des zooms ou des travellings en utilisant les similitudes existant entre 2 frames consécutives pour une détection du mouvement plus intelligente. Attention : cette option est en cours de développement !
B-frames control :
Cette case permet de régler le nombre maximum de B-frames consécutives. Notez que ?1 désactive les B-frames, tandis que 0 active leur gestion pendant l?encodage ainsi que dans le fichier vidéo MPEG-4 sans en placer une seule pour autant. Des valeurs supérieures à 4 sont a priori déconseillées dans la plupart des cas, car les B-frames sont des frames plus compressées que les P-frames et par conséquent plus dégradées que ces dernières (même si elles possèdent moins d'informations).
Cette case permet de régler le ratio appliqué au quantificateur d?une B-frame par rapport aux quantificateurs de la frame précédente et de la frame suivante. Le quantificateur d?une B-frame est en effet lié aux quantificateurs des frames précédente et suivante par la relation suivante :
Quant[B-frame] = ((Ratio*(Quant[frame précédente]+Quant[frame suivante])/2) + Offset)/100
Plus le ratio est élevé, plus le quantificateur d?une B-frame sera élevé par rapport aux quantificateurs des frames précédente et suivante. Notez qu?un ratio de 100 signifie, avec un offset égal à 0, que le quantificateur d?une B-frame est toujours égal à la moyenne des quantificateurs des frames précédente et suivante. Notez aussi que ce ratio est toujours égal à 200 % dans le codec DivX 5 Pro.
Cette case permet de régler l?offset appliqué au quantificateur de toute B-frame utilisée, c?est à dire un terme constant s?ajoutant au produit du ratio réglé ci-dessus par la moyenne des quantificateurs des frames suivante et précédente pour déterminer le quantificateur de la B-frame en cours. Par exemple, un offset de 200 ajoute un +2 au quantificateur de la B-frame. Notez que l?offset ne dépend pas de la situation où la B-frame est employée. Notez aussi qu?une valeur de 0 désactive cette fonction.
Cette case permet d?activer l?option packed bitstream : les B-frames et les P-frames précédente et suivante sont encodées ensemble dans un seul bitstream, dans le but d?éviter un décalage temporel au décodage. Attention : cette option est en cours de développement et hautement déconseillée !
Cette option permet de générer des B-frames compatibles avec les B-frames issues du DivX 5 Pro. Ceci correspond à des restrictions par rapport aux normes MPEG-4 ISO, et impose principalement qu?une B-frame ne peut précéder immédiatement une I-frame. Notez que si vous souhaitez utiliser un FourCC DIVX ou DX50, cette option est indispensable. Néanmoins, elle est conseillée dans toutes les situations.
Cette option permet d?afficher des informations de débuggage à chaque fois qu?une B-frame est introduite dans le fichier vidéo. Cette option n'a d'intéret que dans le cadre d'un test sur la gestion des B-frames par le codec.
Configuration de l?onglet Quantization
Quantization :
Cette case permet de régler le quantificateur minimum utilisé pendant l?encodage pour compresser une I-frame (de 2 à 31). Attention : il est hautement déconseillé de mettre un quantificateur supérieur à 2 dans cette case.
Cette case permet de régler le quantificateur maximum utilisé pendant l?encodage pour compresser une I-frame (de 2 à 31). Notez que le quantificateur minimum doit être inférieur au quantificateur maximum. Attention : il est déconseillé de mettre un quantificateur trop faible dans cette case. Ce paramètre doit servir de garde fou au codec, pas d'entrave permanente à un bon déroulement de l'encodage !
Cette case permet de régler le quantificateur minimum utilisé pendant l?encodage pour compresser une P-frame (de 2 à 31). Attention : il est hautement déconseillé de mettre un quantificateur supérieur à 2 dans cette case.
Cette case permet de régler le quantificateur maximum utilisé pendant l?encodage pour compresser une P-frame (de 2 à 31). Notez que le quantificateur minimum doit être inférieur au quantificateur maximum. Attention : il est déconseillé de mettre un quantificateur trop faible dans cette case. Ce paramètre doit servir de garde fou au codec, pas d'entrave permanente à un bon déroulement de l'encodage !
Ce bouton permet d'accéder au réglage des matrices de quantification à utiliser pendant l'encodage dans le cas où un type de quantification MPEG-Custom a été choisi précédemment. Attention : ces réglages peuvent influer notablement sur la qualité visuelle finale ! N'utilisez donc ces réglages qu'à fins de tests, ou si vous savez vraiment ce que vous faites.
Configuration des matrices de quantification
Custom quantization matrix :
Si le type de quantification est réglé sur MPEG Custom, ce réglage permet de remplir la matrice de quantification utilisée pour compresser les I-frames (ou intra frames). Attention : ce réglage peut avoir un impact majeur sur la qualité globale du fichier vidéo compressé !
Si le type de quantification est réglé sur MPEG Custom, ce réglage permet de remplir la matrice de quantification utilisée pour compresser les P-frames (ou inter frames). Attention : ce réglage peut avoir un impact majeur sur la qualité globale du fichier vidéo compressé !
Si le type de quantification est réglé sur MPEG Custom, ce bouton permet d?importer un couple de matrices de quantification modifiées intra et inter sauvegardées auparavant. Il est fortement conseillé d'utiliser un type de quantification standard comme H263 ou MPEG plutôt qu'une matrice récupérée sur Internet.
Ce bouton permet de sauvegarder le couple de matrices de quantification modifiées intra et inter affichées à l?écran dans un fichier, ceci dans le but de les réutiliser dans un encodage ultérieur.
Configuration de l?onglet Two Pass
Two-pass tuning :
Cette case permet de choisir le pourcentage de bits accordé en plus à une I-frame par rapport à une P-frame pour une image donnée. Notez que les bits supplémentaires accordés à une I-frame donnée à un instant donné proviennent du surplus de bits que possède le codec à cet instant. Si le codec est alors en déficit de bits, les frames suivantes devront être plus compressées pour combler ce déficit.
Cette case permet de ne générer aucun fichier vidéo pendant la 1ère passe d?un encodage en 2 passes, afin d?économiser la place disque. Seul le fichier .STATS sera alors généré. Cette option est conseillée pendant la 1ère passe, car un fichier vidéo de 2 heures compressé avec un quantificateur constant égal à 2 peut dépasser allègrement les 2 GB d'espace disque nécessaire !
Cette case permet de ne générer aucun fichier vidéo pendant la 2ème passe d?un encodage en 2 passes. Ce mode ne sert que si l?on souhaite obtenir des informations sur la 2ème passe sans pour autant créer un fichier vidéo valide. Cette option n'a pas un grand intéret, car il est alors impossible de tester la qualité visuelle du fichier vidéo compressé.
Cette case permet de régler la distance minimum (en frames) en dessous de laquelle 2 I-frames seront considérées comme consécutives et donc traitées différemment des autres via le réglage I-frame bitrate reduction juste en dessous, qui a pour but de compresser plus fortement les I-frames consécutives.
Cette case permet de choisir le pourcentage de réduction de bitrate pour les I-frames consécutives. Notez que la dernière I-frame consécutive est épargnée par cette réduction et est compressée normalement, afin de conserver une qualité normale pour toutes les frames (P-frames et B-frames) suivant cette dernière I-frame.
Curve compression :
Cette case concerne les frames de tailles supérieures à la taille moyenne d?une frame obtenue après compression linéaire de la courbe de bitrates issue de la 1ère passe. Elle permet d?entrer le pourcentage de la différence de taille entre la frame actuelle et la frame de taille moyenne qui sera pris à la frame actuelle pour être redistribué aux autres. Notez que les valeurs entrées peuvent être négatives (de ?100 à 0) ce qui fournit plus de bits aux frames de grandes tailles, ou positives (de 0 à 100) ce qui enlève des bits aux frames de grandes tailles. Notez que 0 désactive cette option.
Cette case concerne les frames de tailles inférieures à la taille moyenne d?une frame obtenue après compression linéaire de la courbe de bitrates issue de la 1ère passe. Elle permet d?entrer le pourcentage de la différence de taille entre la frame actuelle et la frame de taille moyenne qui sera accordé en plus à la frame actuelle. Notez que les valeurs entrées peuvent être négatives (de ?100 à 0) ce qui enlève des bits aux frames de petites tailles, ou positives (de 0 à 100) ce qui fournit plus de bits aux frames de petites tailles. Notez que 0 désactive cette option.
Cette case permet de régler la durée (en frames) sur laquelle le codec peut distribuer des bits pris à une frame précédemment ou prendre des bits à différentes frames pour combler le déficit de bits dû à une distribution trop généreuse. Une durée courte oblige le codec à se défaire rapidement des bits en trop et à prendre rapidement les bits qui lui manquent, tandis qu'une durée longue permet au codec de choisir plus judicieusement les frames ayant besoin de bits supplémentaires ou celles pouvant en avoir moins.
Cette case permet d?utiliser un mécanisme de payback favorisant les frames de petites tailles, c'est à dire les frames de tailles inférieures à la taille moyenne d'une frame, en leur distribuant les bits supplémentaires.
Cette case permet d?utiliser un mécanisme de payback équitable, ne favorisant aucun type de frames en distribuant les bits supplémentaires équitablement aux grandes et aux petites frames.
Si la case est cochée, cette option crée pendant la 1ère passe un fichier .MVH contenant les vecteurs de mouvement calculés au cours de la passe, afin d?être réutilisés directement sans nouveau calcul pendant la seconde passe. Ceci permet une augmentation de vitesse sensible de la 2ème passe, au prix d?une qualité visuelle légèrement dégradée. L?adresse du fichier .MVH doit être entrée dans la case de droite.
Cette case permet de choisir l?adresse du fichier .STATS créé pendant la 1ère passe et contenant les informations utiles comme la courbe de bitrates, les niveaux de mouvement ou encore les types de frames, qui seront utilisées au cours de la 2de passe de l'encodage. Notez que pendant la 1ère passe, le fichier .STATS est créé à l'adresse indiquée dans cette case. Pendant la 2de passe, le fichier .STATS à utiliser est lu à l'adresse indiquée dans cette case. Veillez donc à ne pas toucher à cette case entre les 2 passes !
Configuration de l?onglet Alt. Curve
Alternative curve compression :
Cette case permet d?activer l?algorithme alternatif de compression de la courbe de bitrates issue de la 1ère passe. Notez que le fait de cocher cette case désactive toutes les options du cadre Curve compression de l?onglet Two Pass vu précédemment.
Cette case permet de choisir l?agressivité de l?algorithme de compression de la courbe de bitrates.
L'agressivité Low affecte peu la compression linéaire de la courbe. Elle permet aux frames de tailles comprises entre les bornes High distance et Low distance définies en dessous d'être peu modifiées par rapport à une compression linéaire : les variations intenses de bitrate seront peu réduites. Ce réglage permet aux passages nécessitant un bitrate important de ne pas êre limités par la compression de la courbe, mais les passages à faible bitrate sont alors réduit linéairement par rapport à la première passe, ce qui peut produire une qualité visuelle dégradée sur ces passages.
L'agressivité Medium affecte "moyennement" la compression linéaire de la courbe. Elle permet donc de redresser un peu les frames de petites tailles par rapport à la taille moyenne d'une frame sur l'ensemble du film, et de réduire un peu les frames de grandes tailles toujours par rapport à la taille moyenne d'une frame. Ce réglage permet donc d'éviter les chutes trop importantes de bitrate, sans pour autant entraver exagérément les passages nécessitant un bitrate élevé pour produire une qualité visuelle correcte.
L'agressivité High affecte fortement la compression linéaire de la courbe. Elle redresse fortement les frames de petites tailles, et diminue aussi fortement les frames de grandes tailles. Ainsi, les variations intenses de bitrate sont annihilées et deviennent des variations de faibles amplitudes autour du bitrate moyen : la distribution de bitrate tend donc à devenir constante au cours du temps. Ce réglage permet d'avoir un bitrate quasi constant, au prix de passages exigeants dégradés.
Cette case concerne les frames de tailles supérieures à la taille moyenne d?une frame après compression linéaire de la courbe de bitrates issue de la 1ère passe. Elle permet d?entrer la distance en % avec la taille moyenne d?une frame au dessus de laquelle la qualité minimum relative sera appliquée, via les options en dessous. Attention : ce réglage doit nécessairement être supérieur à 0 (taille moyenne d'une frame), de préférence nettement supérieur à 0. Dans la plupart des cas, il est conseillé que seulement 1% des frames du film soient au dessus de ce paramètre afin de préserver une bonne qualité visuelle.
Cette case concerne les frames de tailles inférieures à la taille moyenne d?une frame obtenue après compression linéaire de la courbe de bitrates issue de la 1ère passe. Elle permet d?entrer la distance en pourcents avec la taille moyenne d?une frame en dessous de laquelle la qualité maximum sera appliquée. Par exemple, un réglage à 100 signifie que les frames de tailles plus de 2 fois inférieures à la taille moyenne d'une frame auront droit au traitement de faveur. Néanmoins, il est conseillé de régler ce paramètre de façon à ce qu'aucune frame ne sort de l'intervalle [Low distance,High distance] : dans ce cadre, un réglage à 100 apparait comme universel.
Cette case permet d?activer le calcul automatique de la qualité minimum relative. La qualité minimum relative d?une frame correspond au rapport minimum de sa taille après compression de la courbe sur sa taille avant compression de la courbe. Il est conseillé d'utiliser cette fonction : de toute façon, ce paramètre n'affecte normalement qu'une très petite partie des frames.
Cette case permet de régler l?influence en pourcents des frames de mauvaise qualité, c?est à dire des frames ayant un faible rapport taille après compression de la courbe sur taille avant compression de la courbe, sur le calcul de la qualité minimum relative. Plus ce paramètre est élevé, plus la qualité minimum relative tend à augmenter la qualité de ce type de frames. Il est conseillé de ne pas toucher au réglage par défaut.
Si la case Enable automatic minimum relative quality n?est pas cochée, cette case permet de choisir de façon manuelle la valeur en pourcents de la qualité minimum relative (de 0 à 100). Encore une fois, il est conseillé de laisser le codec se charger de régler ce paramètre automatiquement.
Cette case permet d?activer le calcul automatique de la distribution du bonus. Le bonus correspond aux bits gagnés au moment de la compression de la courbe en diminuant la taille des grosses frames par rapport à une compression linéaire de la courbe. Ce bonus est ensuite distribué en favorisant plus ou moins les frames de faible qualité par rapport aux autres frames. Il est conseillé d'utiliser cette fonction.
Si la case Enable automatic bonus bias calculation n?est pas cochée, cette case permet d?entrer manuellement le pourcentage du bonus qui sera distribué uniquement aux frames de plus faible qualité, le reste du bonus étant distribué équitablement (de 0 à 100). Il est conseillé de laisser le codec se charger de calculer ce paramètre.
Cette case permet d?entrer le bitrate instantané maximum autorisé dans le film compressé en MPEG-4 (en kbps). Si une fois la compression de la courbe effectuée il restait des passages devant théoriquement bénéficier d'un bitrate instantané supérieur à cette valeur, ces passages recevraient automatiquement comme bitrate la valeur entrée dans cette case. Et le surplus de bits est stocké temporairement dans l'overflow.
Cette case permet de régler le pourcentage du surplus de bits distribué aux passages ayant une taille plus faible que la taille estimée a priori par le codec par frame. Plus le paramètre est élevé, plus le surplus de bits est distribué rapidement.
Cette case permet de régler le pourcentage du déficit de bits pris aux passages ayant une taille plus importante que la taille estimée a priori par le codec par frame. Plus ce paramètre est élevé, plus le déficit de bits est comblé rapidement.
Configuration de l?onglet Credits
Start credits :
Si cette case est cochée, le codec active la prise en charge d?un générique au début du film, séquence qui sera traitée différemment du reste du film en terme de compression via les paramètres du cadre Credits rate reduction en dessous. Attention : si l'encodage s'effectue en mode 2 passes, il est impératif que la gestion des credits soit activée pendant les 2 passes, sans quoi le film sera encodé sans tenir compte de la réduction de taille du générique pour augmenter la taille du reste du film !
Cette case permet d?indiquer au codec le numéro de la première frame du générique.
Cette case permet d?indiquer au codec le numéro de la dernière frame du générique. Notez que le numéro de dernière frame doit impérativement être supérieur au numéro de première frame.
End credits :
Si cette case est cochée, le codec active la prise en charge d?un générique à la fin du film, séquence qui sera traitée différemment du reste du film en terme de compression via les paramètres du cadre Credits rate reduction en dessous. Attention : si l'encodage s'effectue en mode 2 passes, il est impératif que la gestion des credits soit activée pendant les 2 passes, sans quoi le film sera encodé sans tenir compte de la réduction de taille du générique pour augmenter la taille du reste du film !
Cette case permet d?indiquer au codec le numéro de la première frame du générique.
Cette case permet d?indiquer au codec le numéro de la dernière frame du générique. Notez que le numéro de dernière frame doit impérativement être supérieur au numéro de première frame.
Cette case permet de compresser les génériques de début et de fin de film en noir et blanc.
Credits rate reduction :
Si la case à gauche est cochée, cette option permet de choisir le bitrate moyen des génériques en terme de pourcentage du bitrate moyen du reste du film. Il est conseillé de ne pas descendre trop en dessous de 100 kbps pendant les génériques sans quoi ils ne servent plus à rien.
Si la case à gauche est cochée, cette option permet de choisir le quantificateur fixe qui sera appliqué à toutes les I-frames des génériques (de 2 à 31). Cette option fonctionne avec l?option P-frame quantizer en dessous.
Si la case à gauche est cochée, cette option permet de choisir le quantificateur fixe qui sera appliqué à toutes les P-frames des génériques (de 2 à 31). Cette option fonctionne avec l?option I-frame quantizer en dessus.
Si la case à gauche est cochée, cette option permet de choisir la taille souhaitée pour le générique de début.
Si la case à gauche est cochée, cette option permet de choisir la taille souhaitée pour le générique de fin.
Configuration de l?onglet Debug
Performance optimizations :
Cette case active la détection automatique des jeux d?instructions présents sur le processeur pouvant être utilisés par le codec pour augmenter la vitesse d?encodage.
Cette case permet de forcer la sélection des jeux d?instructions à utiliser pendant l?encodage. Notez que le fait de forcer l?utilisation d?un jeu d?instructions non présent sur le processeur utilisé conduit à un crash immédiat du codec.
Cette case permet de régler le ratio de frame dropping utilisé par le codec (de 0 à 100). Le frame dropping consiste à ne pas encoder toutes les frames de la source et à supprimer celles qui ne sont pas jugées comme nécessaires. Notez qu?une valeur de 0 désactive la fonction.
CBR options :
Cette case permet de régler l?intervalle de temps en frames utilisé par le codec pour calculer la qualité d?encodage actuelle à partir de la complexité du passage encodé.
Cette case permet de régler le temps en frames mis par le codec pour adapter la qualité du passage à la qualité d?encodage actuelle.
Cette case permet de choisir le nombre de frames qui auront accès au buffer entre la qualité d?encodage actuelle et la qualité minimum possible.
Message édité par HomiE FR le 25-11-2002 à 21:20:53