En effet comme vous le savez depuis le DivX 3.11 on n'as pas vus venir grand choses !
Certain on fait joujou avec le codec et ont découvers qu'il existait un code dit vki intégré au DivX mais désactivé par défaut.
 
Mais késaquo que le vki ?
 
C'est ce qui est aussi souvent nommé "scene change detect", en gros le codec vas ajouter une image clef à chaque changement brusque d'image (coupure...). Dès lors la qualité est senssée repartir au max pour le plan suivant.
 
D'autres malins ont sorti une version 3.22 du codec, j'ai fait les tests, c'est ni plus ni moins que le codec low motion avec le patch vki appliqué ! En plus ils ont ajouté un copyright dans la fenêtre du codec (trop cons les gars ! Comme si ct eux qui avaient fait le DivX !). Bref aucun intéret à ce codec puisque le codec normal + patch vki apporte un gros plus : le choix entre low et fast !
 
Voici donc les tests
J'ai encodé quelques secondes du film Stigmata. Pour pousser le codec et mieux voir les différences j'ai laissé la résolution originale du DVD (720*320).
Les différentes vidéo sont encodés à 900 kbps. Le nombre de secondes entre les key-frame est de 10 pour le codec 3.11 et de 999 (placement automatique au changement de scène du vki) pour le vki. Pour ceux qui douteraient j'ai aussi testé avec un KF à 10 et le fichier résultat est exactement identique (même taille, même image).
 
Un dernier encodage, fait en low motion 3.11 mais re-taillé ce coup-ci pour que vous ayez une idée de la vidéo réelle.
 
Bon, les liens :
 
Codec 3.11 :
 
Low motion :
www.bheller.com/Video/low311.avi 2.07 Mo
 
Fast motion :
www.bheller.com/Video/fast311.avi 1.74 Mo
 
Codec vki :
 
Low motion :
www.bheller.com/Video/lowvki.avi 2.07 Mo
 
Fast motion :
www.bheller.com/Video/fastvki.avi 1.74 Mo
 
Version 3.11 low motion re-taillé en 512 :
www.bheller.com/Video/low512.avi 1.83 Mo
 
Alors, comparatif
 
Sur la scène du titre :
 
La différence entre les codecs low et fast se vois très nettement sur les passages lent sur les permières images. Le fast est beaucoup plus pixelisé ! On vois très nettement les "blocs" caractéristiques du DivX. En low motion, les blocs sont quasi invisibles.
Par contre, quelques soit le codec (3.11 ou vki), aucune différence !
 
Scène du zoom entre les immeubles :
 
En low 3.11 le début du zoom est fluide mais saccade assez vite.
En fast 3.11, le zoom est quasiment entièrement fluide et saccade sur la fin.
En low vki, tout le zoom saccade !
En fast vki, même topo !
 
Scène de fin (ou on vois l'actrice fumer) :
 
En low 3.11, pas de pb, quelques carrés ça et là.
En fast 3.11, la scène pixelise un petit peu plus qu'en low mais bon, c minime.
En low vki, j'ai une légère impression qu'il y as un peu moins de carrés mais c vraiment peu perceptible.
En fast vki, pareil, un peu plus de carrés qu'en low vki mais moins qu'en fast 3.11.
 
Alors, lequel prendre ? Difficile question... Personellement je conserve le 3.11 mais en baissant la résolution à 512 (héhé ). Le vki apporte-t-il vraiment qq chose ? Je ne crois pas trop...
 
J'ai fait quelques autres tests que j'ai pas mis en lignes (trop gros fichiers). Les résultats montrent que pour une qualité identique, les vidéo vki prennent beaucoup plus de place... Surtout sur les passages avec beaucoup de changement de plan...
 
A vous de voir maintenant
 
A savoir tout de même, que le film soit encodé en 3.11 ou vki, la lecture n'impose pas d'avoir le codec correspondant, c'est à dire que l'on peu lire une vidéo encodée en vki avec le 3.11 et inverssement.
 
Si qq un veux faire un "contre-test" et me montrer le véritable apport du vki dans le DivX, cela m'intéresse beaucoup !
 
Je pense qu'il est meilleur d'inclure le code vki à l'encodeur et non au codec (tel que Mpeg2aviAR ou m4c)... A tester aussi Mais pas le temps now, il est tard

Merci Mounsieur TEST

merci bien, c est bon a savoir.

Yep!
 
Le VKI amène vraiment quelque chose mais le problème est qu'il a tendance à s'emballer dans les scènes rapides en mettant trop de
keyframes.
 
L'idée du VKI est excellente et est utilisée par exemple par
Opendivx ou Real producer.
C'est plutôt la qualité du moteur de détection de changement de scène qui est à remettre en cause.
Dans le cas des codecs patchés, c'est bon pour les scènes qui ne sont pas trop rapides, sinon c'est la cata.
De plus, suivant la valeur du bitrate, il ne mettra pas le même
nombre de keyframes (Plus le bitrate est élevé, moins il en mettra)
Donc oubliez le mm4
Aviirevolution ou m4c permettentent de paramétrer le 'degré' de détection.
Le top c'est le filtre de détection de scènes d'Aviutl qui permet un contrôle manuel avant encodage mais c'est fastidieux!
 
Larini (l'auteur d'Avirevolution) est sur le point de sortir une
version VBR de Mpeg2avi
Wait and see..

Bon, correction.
Larini as déjà sorti une version VKI (et non VBR, ça n'as rien à voir !).
C justement mpeg2aviAR...

Merci Bruce
il bosse, il test, il implémente, il test, il bosse !
 
Trop fort

Arf...
 
Qund on sait pas, on dit pas...
 
Larini va sortir une version VBR de Mpeg2avi
 
http://pub28.ezboard.com/fdoom9smp [...] D=10.topic

Ben je vois pas trop l'intéret de faire un encodeur VBR quand le codec est déjà VBR par derrière ! Il vas se mélanger les pinceaux en beautée !

Salut Bruce,
 
Tout d'abord, ca me fait plaisir de voir que toi aussi tu refutes le terme de VBR... Les posts precedents auront servi a qquechose...  
 
Sinon, pour les tests, je ne conteste pas tes conclusions avec le film que tu utilises. Par contre, le fait que ce soit sur des scenes de scrolling n'est peut etre pas le plus pertinent. En effet, les srcolling font partie des transitions les plus compliquees a gerer pour les codecs video, et tous s'en sortent "relativement mal".  
Je suggere donc de regarder sur d'autres types de scenes. Par exemple, il y a une scene interressante a ce sujet au debut de sleepy Hollow, avant le generique, la scene dans la nuit avec tous les eclairs. Sur cette scene la difference entre 3.11 et 3.11+VKI est assez nette.
 
Il y a un autre test que je voudrais faire, (pas encore eu le temps), c'est sur Enemi d'Etat, sur certaines scenes il y a plein de plan differents qui defilent, et la le VKI doit donner des resultats interessants. J'essaie ca ces jours-ci, je mettrai le topic a jour.

C un peu notre Bruce WAYNE à nous ...

ManuLM : ben fait donc un test sur Sleepy hollow, g pas vus le film (g pas le DVd non plus...). Et publie nous tes résultats

Ben voila, ce week end j'ai relance la compression de Sleepy Hollow avec le codec 3.11alpha + patch VKI.
Par contre, c'est dommage, mais je n'ai rien pour mettre mes tests en ligne, donc je ne pourrais pas vous montrer ca.
 
Allons y pour les parametres de compression :  
Low motion, KF 999, rate 900, resolution 512*288, avec et sans vki. Encodage avec le rippack V2, donc mpeg2avi.
 
Ben par rapport au film que j'avais deja compresse avec le 3.11 alpha, la difference est vraiment importante en termes de qualite. Les changements de scene (il y en a beaucoup) passent vraiment bien, et je suis gagnant sur la taille finale du film (690Mo en VKi contre 708, j'avais du couper le generique de fin ).
 
Par contre, remarque generale, je trouve que en 512*288, l'image est un peu floue, par rapport au 640*368 ou au 720* ???.
 
Les scenes sur lesquelles les differences sont tres nettes :  
La scene avant le generique avec les eclairs, ainsi que la scene ou on voit le passe du cavalier sans tete, avec les scenes de combat...
 
Si tu veux te convaincre de l'efficacite du patch, Bruce, loue toi le DVD et essaie l'encodage, tu verras que le patch fonctionne tout de meme pas mal.
 
A +

Ben déjà pour voir j'ai essayé sur la même vidéo qu'avant mais en 512 avec le vki.
Résultat :
 
www.bheller.com/Video/low512vki.avi
 
Au début on remarque très nettement deux "saut" de qualité du au vki... pour le reste c kif kif avec le normal...

De mon coté j'ai fait 2 tests.
un en 1500, low motion -> bon la franchement pas de difference, c'est excellent des 2 cotés
l'autre en 700. La c'est plus significatif -> il y a un leger mieux pour le vki, surtout lors de mouvements de camera, mais bon pas trop violents sinon ça saccade...

kestion bete
on l'active comment vki ?
ensuite :
il marche avec flask je suppose mais et mpegavipx ?
il faut mettre 999 c ca ?
merci d'avance
@+
dragon

je pense avoir trouve c un patch en fait a telecharger et a ramplacer par les anciens dll. donc comptible avec le prog qu'on utilise. et ca change rien a la facon de parametre avec flask par exemple ?
par contre 999 je comprend pas, je suis toujours limite a 6000 ?
c ou 999 dans flask par ex ?

wow je sui grave fatigue voila que 999>6000
lol
vaut mieu que j'en rigole sinon je vais me suicider de honte
lol lol lol

Ben en effet il faut changer les dll du codec, ensuite tu encodes avec KF=999, voila, c'est tout. Pour la resolution, 512 est a priori une bonne base pour la resolution horizontale.
A +

Dragonxxx : confond pas les paramètre des KF et celui du débit (en kbps...)

si il met une KF c'est que sa taille est plus petite qu'une deltaframe !!. La détection (pour le patch actuel) est simplissime ==> si la deltaframe est trop grosse c'est qu'il doit y avoir une "cassure". Alors on fait une KF qui est zolie et qui prend moins de place. c'est donc d'autant plus efficace qu'on est en haute résolution (hum ... je vais pas relancer ce débat ici )

 
dacocac ! mais c'est assez complexe donc ... En fait le pb c'est qu'il n'y a pas de solution universelle marchant pour TOUS les cas. Le travelling testé par bruce est un bon exemple : KF ou pas KF ?? La soluce actuelle marche surtout dans les très nombreux changements de point de vue (ou le cas des éclairs ). Faites le compte : sur 20 secondes en plein milieu du film combien y a t'il de changement de plan (ou de caméra) ?
 

Pour de forts taux de compression peut être (et encore parce que j'ai pas testé, vu que descend jamais en dessous de 1200). Par contre, viens voir ma version de matrix (j'en suis assez fier, vu le nombre de fois que je l'ai encodé différemment ) : les scénes les plus rapides sont d'une beauté allucinante.
 

complétement faux (et j'ai fait le test, cf mon topic : tests du WE attention aux yeux ) pour des encodages "normaux" (style entre 1200 et 2100, pas un poil de différence en nb de KF et la taille moyenne KF varie peu)
 
> Bruce : tu veux que je te montre encore cette fois ?
après flask, puis WMP, le VKI ?? (tu sais pourtant que j'en ai fait des tests ... )
je t'ai également grattiné un petit test sur lame ....
 
Honnètement, c'est depuis le début du divx qu'on attendait cette modif avec des potes : on savait depuis un moment que la taille des deltaframes divergeaient en exponentielle lors de "cassures" dues au changement de plans. J'avoue qu'on avait perso mis entre parenthése le divx, car pour encoder la manganimation très rapide on attendait mieux ...)  
 
Pour le travelling le pb sera résolu avec les codecs incluant de la vectorisation/reconnaissance d'objet/schéma. c'est en cours et ça s'appelle MPEG7, déjà bien avancé (60-70 %) sur le papier mais encore loin d'être codé : pour exemple le MPEG4 est finalisé depuis 1997 ... Si vous voullez vous projetter (très) loin dans l'avenir allez visiter les pages du Motion Picture Expert Groupe Consortium (et les pages gnu associées )
 
So wait and see ...
 
Au fait pour ceux qui maitrisent j'ai un petit pb par là :
http://forum.hardware.fr/sqlforum/ [...] config.inc

Je ne discuterai pas sur les critères qualitatifs vu que l'on peut dire ce que l'on veut et c'est souvent histoire de gout..
 
Par contre je confirme
 
Suivant la valeur du bitrate, il ne mettra pas le même nombre de keyframes (Plus le bitrate est élevé, moins il en mettra)  
 
"complétement faux (et j'ai fait le test, cf mon topic : tests du WE attention aux yeux ) pour des encodages "normaux" (style entre 1200 et 2100, pas un poil de différence en nb de KF et la taille moyenne KF varie peu)"
 
Complétement vrai., confirmé par un tas de gus qui se sont cassés les dents en ayant voulu faire du mm4/VKI avec ce codec
Et un test dans ce cas ne prouve rien, par contre un seul avec un nombre de KF différents suffit..
 
Qu'est ce que cela veut dire, normal entre 1200 et 2100, c'est ridicule. Il n'y a pas de fourchette 'normale'
 
Mais peu importe.
Fais un film entier et non un test de quelques minutes avec un bitrate de 1200 et un autre de 2100
Ou alors fais un test avec un bitrate de 900 et un autre de 6000
Et regarde ensuite le nombre de KF
Mais tu le dis toi-même le moteur se base sur la taille de la deltaframe comparée à la KF et cette taille est + facilement dépassée quand le bitrate est bas. CQFD

 
En effet, tout bon encodeur mpeg se doit d'avoir une detection de changement de scene. Ce patch, quand je l'ai vu arriver, je me suis dit que ca allait donner. Il est en plus super simple a implementer car de toute facon le codec se tape le codage delta, donc evalue la difference avec l'image precedente. Il suffit alors de rajouter un critere de decision pour choisir quel codage tu fais (intra ou inter)
 

 
En ce qui concerne les travelings, il existe deja une notion d'objets et de vecteurs de deplacement dans le mpeg4 (j'ai la norme ISO sous le nez ) mais rappelons le, le DivX ;-) n'est pas le mpeg4 full feature, ce n'est qu'une toute petite partie du mpeg 4. De plus la premiere version de la norme (iso/iec 14496-2) est sortie en decembre 1999 et pas en 97. D'ailleurs des updates continuent d'arriver. La norme n'est donc pas si vieille que tu le dis...
 
Plus d'infos si tu veux par la :  
http://www.m4if.org/
 
A +
 
PS : Si tu as fait tes reglages aux petits oignons sur Matrix, ca te dirait de nous les transmettre en detail plz

--Message édité par ManuLM--

->Atlantis
Pour ton essai
 
DVD2Avi > VFAPIConv-1.04-EN > AviUtl0.96i-e > lm4c
 
Le passage par VFAPIConv est inutile vu que Aviutl lit en natif les fichiers créés par DVD2AVi (.d2v)
 
Un guide d'aviutl+plugin m4c dispo en anglais sur http://go.to/doom9
 
Personnelement, je préfère lancer m4c (ou Icem4c ou Idm4c) en ligne de commande avec Virtualdub en frameserving.
Bcp + rapide
 
Mais je suis en win2k et apparemment certains ont des difficultés
en win9x.

euh ton mm4 c'est bien le patch pour divx3.11 ?? parce que j'ai fait le test sur un film entier (matrix), approximativement au valeurs 1200, 1500, et 2100. Si on descend en dessous de 1200 je sais pas (là ça peut varier). Je vais voir ce que je peut trouver comme film assez rapide et faire si possible les tests à 900 et 6000 . Au fait tes gus ils ont bien ouvert le film sous vdub et demandé les propriétés pour avoir leur nb de KF ? (juste histoire qu'on soit bien homogène sur la méthode )
 

à ouais l'iso mais le MPEG ne dépose l'iso qu'une fois que les commanditaires du travail l'ont étudié/approuvé etc ... La preuve c'est que certains site gnu "indiscrets" en ont fait état depuis la fin de ma spé (c'est à dire en 1997) Et si il a des updates, ça doit venir du mpeg7 : taxent des idées facilement applicables. Enfin je pense  
 

c'est bien ce que je me disais ...
 

merci bien ! j'y vais ce pas ...
 

et t'aurai pas une ptite sauvegarde de la ligne de commande des fois ?? C cool car je vais pouvoir ainsi tester deux méthodes différentes de réduction de bruit : Avitul+temporalNoiseRed et Vdub+VHS. (le rapide Vs le balèze ...)
 
Merci bien ...

Oui, il s'agit bien du divx3.11 patché.
Le patch à appliquer sur les codecs marche de la même manière
Je ne doute pas que tu aies pu avoir le même nombre de KF dans
ce cas mais ce ne sera pas toujours comme cela, loin de là..
 
Matrix est un film qui se compresse tès bien, même avec un bitrate de 6000 et il n'est pas incohérent qu'entre 1200 et 2100, il n'y ait pas de différence entre les KF.
Oui, ils ont regardé le nombre de KF avec Virtualdub.
Ils n'arrivaient pas à faire un mix et il ne comprenaient pas pourquoi.
Si tu veux de rendre compte de ce comportement facilement, choisis un trailer.
 
pour m4c en ligne de commande
 
- Si tu es en win2k, no pb
- Si tu es en win9x, c'est la galère et il n'y a pas de solution universelle; je pourrais t'indiquer celle qui marche dans cerains cas
 
Sinon
1)DVD2AVI+VFAPICONV->movie.avi
2) Charger movie.avi ds Virtualdub, Crop,Resize,filtres etc..,
sélectionner les frames à encoder (Important: sinon le process est + long)
3)menu File, Startframeserver,accepter le nom par défaut, cliquer sur start, ensuite ne pas sauver avec une extension .vdr mais .avi du style matrixvdr.avi
(Il faut avoir, juste une fois, installé les handlers pour que Virtualdub fasse du frameserving. rep de virtualdub, cliquer sur Auxsetup, cliquer sur install Handler)
4) dans une session dos , taper par exemple
 
m4c -vL -r700 -k9999 -s4 matrixvdr.avi result.avi
 
-vL= codec Divx
-r700: bitrate de 700; suivant les films on peut descendre bcp +bas jusqu'a 500 ou monter jusqu'à 1200.
-k9999; keyframes (régulières) toutes les 9999 s, cad jamais
-s4 moteur de dtection de scène à 4; certains le mettent à zéro(pas de détection); 4 ou 5 me convient; à tester pour chacun et en fonction du film
 
La taille finale n'est pas aisée à 'calculer'.
La plupart du temps, tu peux te baser sur ce que donnerait le bitrate indiqué en ligne de commande multiplié par 1,2
 
 
Les variantes de m4c
-idm4c permet de faire jusqu'à 4 encodages différents sans multiplier le temps final par 4
-icem4c permet de sauter, suivant certains paramétrages, certaines KF trop rapprochées, accélère le processus, fait baisser la taille finale.

page enregistrée, tests à partir de ce soir. je vous tiens au courant !!
(et merci encore !! )

je viens de comprendre ce que mm4 veut dire   (je connaissais le concept mais pas le nom)
c'est normal qu'ils aient eu des pb en haute compression  

bon ben j'en suis là :
1/ AviUtl : enregistré sur disquette evidemment foireuse => ne marche toujours pas.
2/ Vdub : sous W98 la version 1.4 ne marche mais la 1.3 marche (du moins elle commence son boulot car cette fois c icem4c qui dit qu'il peut pas ouvrir un avi)
3/ Flask : toutes mes versions merdent (alors qu'il y a 2 semaines sur l'ancienne install de Win tout marchait bien ...) et me renvoit "AviOpen**** impossible". j'ai reinstallé WMP (la dernier fois ça a suffit) et même DX7a et rien ...  
 
donc toujours pas de test tant que j'aurai pas trouvé ce qui merde ...
c'est chiant car seul mpeg2avi marche mais j'ai un superchallenge sur les bras : Anna et le roi. Même en 2075 VKI et tout et tout j'arrive pas à avoir une qualité satisfaisante.
 
et pour matrix :
Matrix   2 CD 80'  
2h10'37s environ (131 minutes) / ramené à 2h03'45 (124' )
16/9 PAL 25fps flask HQBC => (720*272)  
DIVX low VKI 15 100 2267  Débit : 2267 kbits  
pistes audio : français / anglais (lire avec bsplayer)  
soustitrage anglais dispo (=> bsplayer)  
 
coupure au moment ou neo tend la main pour rentrer chez l'oracle.
Attention coupure au poil et léger overburn du cd à prévoir.
Mais matrix ou Men In Black (2400 même conditions) c'était trop facile comparé à Anna et le Roi ...

Vus les questions sur le codec 3.22 et autres patch vki je remonte le thread

Re-up cause de la fonction recherche de caca qui marche tout plus

avec le patch VKI on diret que j'ai moin tendance a avoir des saccades dans les films ! qui peux confirmer ?

Heuu j'ai telechargé toutes les video pour me faire une idée de la difference et y'a comme un pb.
Chez moi elles sont toutes pourries, saccades, pixels enormes ...
Celles en fast sont vraiment degueulasses et celles en low sont pas bien mieux, il n'y a que celle en 512 qui est potable. C'est l'encodage qui donne ça ou ma machine (duron@1000 + 256MB PC133 cas2-2-2 + Geforce 2 GTS) ????
 
ça le fait chez qq1 d'autre aussi? car j'ai d'autres divx et ceux la sont nickels ...

Ben j'ai poussé le truc à fond puisque la scène à encoder est très difficile ! Seule solution potable, baiser la résolution !

chez moi les codecs vki me font des macroblocks, meme en 6000

Je répete qq chose que j'avais déjà dit... comme vous le savez le code du vki était intégré au DivX depuis le début mais désactivé. De même pour les codecs officiels Microsoft. A votre avis pourquoi ?  

pourquoi quoi ? car ces pourri ? on c'est mieux ? car pour moi j'ai on dirait que j'ai moin de saccade !
 
alors personne a vu ?

pourquoi ? mais c'est simple : pour enlever le lock après coup et dire que l'on a tout révolutionné . c'est classique .
regarde nVidia et ses 'Quadro'. Une fois que c'est éventé, évidemment on le sait, mais sinon on se fait avoir comme des pigeon.
Perso le vki n'apporte que des bénéfices.

Mais bien sûr...  
 
Et la marmote...
 
Si c pas activé c qu'il y as bien une raison, et elle est finalement simple, c que c la galère ! Parfois c mieux, mais souvent c moins bien... donc... (il met souvent bcp trop de KF ou alors pas assez...).

ben dans le cas d'encodage à 'haut débit' (> 1200) c'est tout le temps mieux en tout cas (ah bon je suis lourd ?? )

j'ai l'impression de parler dans le vent ? alors personne a vu une dif a la lecteur ?
 
perso je laisse le keyframe a 3 et le resultat est correct !