salut.
 
 
Quelqu'un peut m'expliquer ce que fait exactement compressibility check  en pratique ?  
 
 
De plus, si j'obtiens 72 % , est ce que ca veut dire que le codec sature par rapport au bitrate que j'ai mis ?? qui est pourtant tres bas . il represente quoi ce chiffre finalement?
 
Certains disent que si l'on monte la resolution,finalement on augmente la taille finale du avi (parce qu'il ya plus de bit par frame)
 
Mais quand on mets le bitrate ds gknot . ex : 900kbit/s  pour un pal,normalement le codec doit s'arranger pour respecter ce bitrate . Je parle en moyenne total sur tout le film . Alors pourquoi la taille peut varier enormement  au final .
 
 
Merci pour vos infos .

pffff je m'étais déja penché sur la question mais voici ce que je crois avoir capté:
 
En gros si tu dépasse les 70-75% de compressibilité c'est que le codec est saturé au niveau de ses besoins en bits/pixel==> tu n'atteindras pas la taille que tu t'es fixée quand tu as calculé ton bitrate. Du coup tu peux augmenter ta résolution afin de mieux "saturer" le codec puisque qu'en augmentant le nbr de pixels tu vas augmenter le bitrate effectivement utilisé (en supposant le nbr de bits/pixel contant ce qui n'est pas forcément le cas mais ça aide à saisir le concept). Par saturer le codec j'entends donc lui faire utiliser effectivement la moyenne du bitrate calculée pour obtenir la taille finale de fichier que tu souhaites.
 
Donc:
 
1. Tant que ta résolution est insuffisante tu ne satures pas le codec et du coup il n'utilise pas le bitrate fixé==>tu tapes en dessous de la taille prévue: Celle ci va augmenter au fur et à mesure que tu augmentes la résolution.
 
2.Dès que tu passes au dessus du "seuil" de la résolution qui sature le codec tu ne dépasses pas la taille fixée par le bitrate puisqu'il est au taquet niveau débit mais tu as de + en + de macroblocs.
 
Voilà, j'espère ne pas avoir raconté trop de conneries.

[jfdsdjhfuetppo]--Message édité par johnbroot le 25-05-2002 à 01:23:44--[/jfdsdjhfuetppo]

Merci john .
 
un petit up pour ceux qui ont des precisions a rajouter .

 
ils sont les bienvenus.
(au passage j'ai édit 5x le message ci dessus donc n'hésite pas à y rejeter un coup d'oeil).
 
Pour ce que fabrique gordian pour le test je crois aussi me rappeler vaguement qu'il compare sur x% (5 par défaut) les résulats obtenus en encodant à ton bitrate et à 6000bits/s...
Mais là c'est très fumeux (j'avais lu ça sur le forum doom9 par the wef himself) et encore + approximatif

oui,on en est a peu pres au meme niveau de connaissance sur ce sujet . Je savais que  gknot fait une passe avec le bitrate a fond les gamelles mais ce % ,je ne sais pas encore comment il le calcule .
 
il ya tellement de choses encore obscures pour moi la dessus .    
 
 
a+ pour en savoir +

Pour le pourcentage que tu rentre (ie 5%) c'est la "quantité" du film qu'il va encoder en une passe (theoriquement si tu mets 100% il te fait un encodage total).
 
Je sais plus si l'encodage se fait à 6000 ou en quality based à 100%, par contre le pourcentage que l'on recupere c'est le rapport bits/pixels du fichier final divisé par celui que l'on lui propose.
 
Apres pourquoi 50-60% sont conseillés, on peut supposer que le codec peut rendre l'image differente d'un point de vue couleur ou autre sans que l'oeil humain y trouve à redire (sur les degradés par exemple).
 
NB : le dernier paragraphe est purement speculatif..

Bon ça y est je suis en mesure d'expliquer précisément comment gordian travaille pour faire son compressibility check !
 
Quand je dis précisément je ne vais tout de même pas me perdre dans les détails (peut être un tutorial détaillé un de ces jours avec explication sur l'effet des quantizers qui est un paramètre au moins aussi important que le bitrate lui même, en fait les 2 sont interdépendants)
 
Bon alors....
 
le mieux est de bosser sur un exemple concret: Hop, je veux faire tenir un film sur 700 Mo et je décide de faire un compressibility check sur 5% du film ce qui représente par rapport à la taille visée à un fichier de 35 Mo (=5% de 700Mo). Bon now on lance le test. Gordian configure le codec divx à son débit maximal: 6000kb/s (en fait ça revient surtout à imposer les quantizers à 2=>compression spatiale minimale ) et lance la 1ere passe sur les 5% puis récupère la taille du fichier obtenu en fin d'encodage dans le fichier log créé!
 
Finallement il fait le rapport taille visée (35Mo)/taille du fichier obtenu à 6000kbps (que l'on ramène à 100 pour avoir le résultat en %)===> taux en % de compressibilité
 
Ex: Si le fichier obtenu à 6000kbps pèse 50Mo on obtient
 
(35/50)x100 = 70% de compressibilité. voili voilo
 
Pour le détail de l'effet de résolution des quantizers etc j'expliquerai ça une prochaine fois....  
 
PS: Je pense avoir bien saisi le concept et espère ne pas avoir raconté de conneries , mais si c'est le cas les critiques (constructives) comme les questions sont les bienvenues

[jfdsdjhfuetppo]--Message édité par johnbroot le 25-05-2002 à 18:02:37--[/jfdsdjhfuetppo]

d'apres ce que tu dis john, donc plus le % (resultat du compressibility check) est eleve plus l'extrait est gros .Donc moins il est compresse .
 
Or c'est contradictoire avec ce qu'on preconise .Cad que  lorsque % est trop haut ,augmenter la resolution ,ce qui a comme consequence d'augmenter la taille finale.
 
 
Qu'est ce que tu en penses ???

 
bien vu comme raisonnement mais en fait c'est "l'inverse" (enfin c'est un peu plus compliqué)
Oh my god! How is it possible?
 
En fait tu as raison plus le film est compressible et plus sa taille va se rapprocher du resultat obtenu avec la version en 6000kbps! En fait il faut voir les choses à l'envers. N'oublie pas que l'échantillon des 5% (les fameux 35Mo de mon exemple) sont la seule référence à prendre en compte. Si la compressibilité augmente ça veut surtout dire que la taille du fichier encodé à 6000kbps diminue et se rapproche de nos 35 Mo!! car je le répète ce sont les 5% de la taille visée qui servent de référence (ces 35Mo sont le résultat d'un simple calcul pas d'une passe d'encodage).-->C'est la taille de l'échantillon 6000kbps qui varie en fonction de la résolution/des filtrages (antibruit et type de resize).
 
Alors qu'est ce que ça veut dire? Une grande compressibilité indique que la taille visée a peu de chances d'être atteinte puisque l'on obtient à peu près la même taille de sortie à très haut bitrate (6000kbps) et à faible bitrate théorique (celui calculé pour théoriquement obtenir notre fichier de 700Mo). Je dis bien théorique puisque le calcul du bitrate donné par la calcu de Gordian (comme toute autre calculatrice) fait juste bitrate=taille/temps donc le résultat escompté de 700 Mo est celui qu'on obtiendrait en imposant un bitrate constant ce qui n'est évidemment pas la manière de bosser d'un codec "intelligent" comme divx travaillant à bitrate variable pour s'adapter à la + ou - grande complexité des scènes.
 
Pour terminer si la compressibilité est grande ça veut dire que la taille visée ne sera pas atteinte puisque comme je l'ai déja dit il y a trop peu d'information à coder par rapport au débit binaire disponible: Le codec divx se contentera de délivrer le max de débit nescessaire pour encoder un contenu "pauvre en info" et ce débit réel sera en deça du débit théorique et donc l'occupation moindre.  
 
Pour illuster la chose je prends un exemple extrème et très con: Imagine une séquence où il y a une image totallement monochrome (écran totallement vert par exemple) pendant X minutes: La taille du fichier sera la même que tu l'encodes en 1000 ou 6000kbps puisqu'il n'y à quasiement aucune info à coder (l'image n+1 est identique à l'image n et le bloc de pixel n+1 est identique au bloc n)
 
Bon j'espère avoir été clair et encore une fois avoir évité les conneries. Well time to go clubbing. Comme d'hab n'hésitez pas à poser + de questions ou à me corriger.

[jfdsdjhfuetppo]--Message édité par johnbroot le 25-05-2002 à 23:04:50--[/jfdsdjhfuetppo]

oui ,c'est l'inverse . Je m'en suis rendu compte apres

JohnBRoot:
 
voila ce que j'ai trouve sur doom9 qui explique tout et qui permet de faire un test de comp avec divx 5.03 qui est incompatible avec gknot .
 
 
en gros  comp = (taille desiree)/ (taille obtenue en 1 passe qualite based 100)
 
 
copier/coller de ce que j'ai trouve :
 
 
I suggest a manual method to make compressibility test with DivX 5.03:  
 
 
1 Check "Compressibility Check" in GKnot and save your avs file.  
 
2 Open the avs file in VDub, select 1-pass quality based and set the quantizer to 2 (set the other options as you want).  
 
3 Save to an avi file.  
 
4 Open the avi file, go to File > File Information.  
 
5 Take a look at the row "Min/avg/max/total delta frame size", take a note of the "avg" value.  
 
6 Multiply "avg" by the total number of frames in your movie, so you have the "predicted size" at quality based 100%.  
 
7 Take a note of the "Video Size in KB" in GKnot, you must multiply this value by 1024 to obtain the size in bytes.  
 
8 100 * "Video Size in bytes" / "predicted size" is an approximation of the comp.test value.  
 
 
This method is not 100% accurate with b-frames enabled.
 
 
 
l'auteur precise que cette methode marche avec n'importe quel codec mais qu'elle n'est pas sur si on utilise des B frames avec divx 5.03 . Le resultat obtenu est ds ce cas 10 a 15 % inferieur a la realite.
 
 
ps:j'ai essaye et j'ai obtenu une valeur tres credible .
 
@+

chris:
 
A ça c'est cool justement parceque j'ai quelques animes à réencoder et j'espère gagner en qualité justement en utilisant le new divX5.03 et en utilisant un piste son vorbis...
 
En passant, qu'est ce que tu penses du nouvô 5.03 car j'espère que cette fois les trucs style GMC ou psychovisualehancement vont réellement apporter quelquechose.
 
 

tiens, toi aussi
ça m'interresse

 
mé non puisque tu vas utiliser anime2vp3