J'ai observé l'histogramme d'encodage de virtualDub, et j'ai vru comprendre que les traits rouges correspondent aux Keyframes, dont il parait qu'il ne faut pas trop en mettre, sous peine de perdre en qualité sur l'ensemble. Le problème, c'est qu'en Xvid (dans mon cas), certaines scènes sont toutes rouges. Ouvert sous Vdub après la compression, ce genre descènes correspond à des mvt très rapides ou très détaillés (genre : étincelles).
 
Ma question est de savoir s'il existe un paramètre pour limiter la densité de KF (DivX ou XviD), et s'il est souhaitable de le faire.
J'ai rien trouvé sur le forum à ce sujet. Merci

ben je crois que dans vdub tu peux fixer la frequence des keyframes (en millisec), c'est quand tu defini la compresssion.

Bah oui, les keyframes, point trop n'en faut, car étant un peu plus compressées (normal, vu que c des images entières), la qualité d'une kf n'est pas top top.
 
C'était d'ailleurs le problème avec les anciens patchs VKI Variable Keyframe Interval (ou Scene Change Detect, ou DivX 3.22 etc.) : ca insérait une foutue floppée chiée de KFs dès qu'y avait un mouvement trop rapide, bonjour la merde.
 
Le seul truc intelligent de ce côté là, c'était le SBC : il fait du Variable Keyframe Interval (insertion de KF à chaque changement de scène plutôt qu'à l'intervalle régulier paramétrable avant la compression) mais on peut préciser l'espacement minimum entre 2 images-clés successives (genre "au moins 1 seconde entre 2 KF" ) pour pallier au problème... c le param "min kf interval"
 
Même le DivX 4.12 n'est pas exempt, ca arrive qu'il foute une dizaine de KF à la suite et apparemment le XviD souffre du même problème

[jfdsdjhfuetppo]--Message édité par Indiana Jones--[/jfdsdjhfuetppo]

 
Je sais. Mais un format tel que le Xvid, Le DivX 4 et le SBC introduisent intelligeamment des Keyframes à chaque changement de scène, ce qui est un avantage. Le problème, c'est que le moteur de détection de changement de scène se laisse pièger dans certains cas, ce qui est peut-être un défaut, et que j'aimerais dans ce cas pouvoir éviter.

cf indiana jones

 
Merci Indiana. Pas moyen de remédier alors ? Je me rapellais bien avoir lu cela dans ta traduc de Koebi : curieux que ce problème demeure avec le XviD. En travaillant sur le .stat, c'est possible (peut-être titanesque, remarque)

Bah disons que c'est pas géré de base dans les codecs, ce qui est fort dommage (et ne devrait pas être si difficile à implémenter).
Bidouiller les stats ca doit être lourd !!
 
En tout cas, ça prouve à quel point le SBC est abouti dans son fonctionnement...

 
C clair. Je crois que j'ai pas mal à apprendre avec le SBC... dommage qu'il nécessite une telle adresse pour produire des encodages de très bonne facture.

Justement, maîtriser le SBC revient à comprendre le fonctionnement de ce genre de codecs et toutes les techniques de compression/spécifications etc. C'est hyper formateur (toujours agréable de comprendre pkoi faut pas encoder les bandes noires, plutôt que se contenter de ne pas le faire), mais c chaud de s'y mettre

Dans le paneau de configuration du codec XviD lors de l'encoage, il y a un parmètre qui s'appelle "Max keyframe Interval"; devine à quoi il sert
 
250= 250 frames entre 2 keyframes au MINIMUM = 10sec pour un film en 25 images/s.
 
 
Dans VirtualDub à "Options->Preferences->Scene", il me semble que les 2 réglettes permettent justement de détecter un changement de scène; mais je n'en suis pas sûr !!

El_ShAmAn___ a écrit a écrit : Dans le paneau de configuration du codec XviD lors de l'encoage, il y a un parmètre qui s'appelle "Max keyframe Interval"; devine à quoi il sert   250= 250 frames entre 2 keyframes au MINIMUM = 10sec pour un film en 25 images/s.

 
Non..Ce n'est pas le minimum mais le maximum donc le but est exactement l'inverse, à savoir forcer une keyframe ts les X frames si le moteur de détection n'en a pas mise..

 
 
Ben oui, j'ai dis n'importe quoi sur ce coup  
 
Erreur involontaire, (pardon !)

[jfdsdjhfuetppo]--Message édité par El_ShAmAn___--[/jfdsdjhfuetppo]

El_ShAmAn___ a écrit a écrit : Dans le paneau de configuration du codec XviD lors de l'encoage, il y a un parmètre qui s'appelle "Max keyframe Interval"; devine à quoi il sert   250= 250 frames entre 2 keyframes au MINIMUM = 10sec pour un film en 25 images/s.     Dans VirtualDub à "Options->Preferences->Scene", il me semble que les 2 réglettes permettent justement de détecter un changement de scène; mais je n'en suis pas sûr !!

 
En effet, c'est l'intervalle MINIMUM qui nous intéresse sur ce coup là
 
Sinon les params de SCD dans virtual dub n'entrent en jeu que si le codec le permet

Si si...
 
Il y a un truc pour suprrimer les KF qui se mettent à la chaine...Il s'agit du bien aimé MorphiX de BlackSun !
Ou alors, à faire "à la main"

J'ai songé à ce tupe de logiciel (il en existe un autre, à ce que j'ai vu sur le forum de Doom9). Mais je ne pense pas que cela fonctionne avec le XviD. Dommage qu'il faille une béquille au codec pour ajuster sa démarche.
Mais puisque Blacksun travaille beaucoup sur le XviD, peut-on espérer un XviD-SBC prochainement ?

 
Laisse tomber...
 
Si tu me donne un extrait de fichier stat de Xvid, je te dit en 2 min comment supprimer tes KF en trop  

Sans te le donner, tu peux me le dire qd même ?
 
Je sens un degré d'ironie dans ta réponse, ms je détermine pas la raison.

Ben... disons qu'en général, dans ce genre de fichier, pour chaque frame il est indiqué si elle sera encodée en KF ou pas... Donc il suffit de changer le réglage et hop (enfin, c'est le cas pour DivX 4, le SBC et même le VBR du 3.11)
 
Quand à l'ironie, c'est pas pour toi, excuse moi... C'est juste un truc entre moi et les modes 2pass...
 
Edit : Pour DivX 4.0, le réglage des KF c'est la colonne intra  
Ca pourrait t'aider...

[jfdsdjhfuetppo]--Message édité par Ciler--[/jfdsdjhfuetppo]

Ok, je verrais celà un peu plus tard. Merci bcp.

MorphiX modifie des ".log" du DivX4.xx à ce que je sache, mais le XviD utilise les ".stats", les même que Nandub.
 
 
Je crois avoir trouvé
 
Il faut ouvrir le ".stat" généré lors du 1er pass en XviD (ou avec Nandub, ils sont compatibles), dans GordianKnot.
Puis, sous l'onglet "Stats File Editor", il y une partie qui s'appelle "Key-frame" et un réglage qui se nomme "Min.dist", je pense qu'il pourrait être intéressant
 
Ensuite, il suffira de sauvegarder le nouveau ".stats".
 
Précision:
Il faut désactiver "Motion Correction" et "Luma correction". Il est intéressant d'activer "Credits" et de donner la position de départ du générique de fin pour en diminuer le bitrate.
Le débit du fichier final se rêgle sous l'onglet "Bitrate", en sélectionnant le codec DivX4.xx (car 1KBits=1000Bits, ICI).
 
 
Dans la configuration du codec XviD, il suffit alors de charger le ".stats" du 1er-pass et le ".stats" modifié par GordianKnot, et de faire le 2e-pass.

pour les détails.

El_ShAmAn___, il existe une manip semblable décrite par Doom9 en complément à son tuto XviD. Je sais pas si c'est la même, et de tte façon j'avais pas pigé ce que je faisais.
 
Je réessairais au terme de mon encodage avec les passages à problèmes.
Merci

Je comprends mieux pourquoi j'ai été beaucoup moins enthousiaste avec le Xvid pour Jurassic Park que pour le Monde Perdu !
 
Je viens d'ouvrir un encodage sous virtualdub, et je peux lire certaines scènes rien qu'en avançant de KF à KF (shift + --> ) : il y en a partout à chaque éclair, ou même à chaque changement significatif de luminosité. Lorsqu'un objet bouge très vite, idem : Kf à chaque image. Dans l'ensemble, sur ces scènes, la qualité est très mauvaise : l'image ressemble plus à un damier qu'à une bestiole du crétacée sous la pluie.
Pour info, le SBC dont j'ai heureusement gardé le rip s'en sortait bien mieux (KF beaucoup plus espacées)
 
El_ShAmAn___, le min.distr du KF, je le place sur quelle valeur ? 10 ? 20 ? Ce qui signifie que j'en aurais 1 toutes les 10 frames au grand maximum ? Actuellement, je peux pas tester, j'ai une deuxième passe en cours (avec temporal masking), et j'en ai pour 7 plombes...
 
Sinon, est-ce qu'il ne vaut pas mieux encoder la scène à part, et la coller ensuite ?

Perso, j'utiliserai 25, voire 50 (valeur par défaut dans GordianKnot).
 
 
Si vraiment la qualité générale de la vidéo est bonne, sauf cette partie, tu peux en effet réencoder cette scène à un débit plus haut et la recoller ensuite.

Je vais sans doute repartir pour une nouvelle passe...
Je ferais qq essais sur la scène en question, avec et sans Gordian, pour mesurer la qualité introduite par la modif du .stat
 
Si j'ai bien compris, une KF bouffe du Bitrate, est de mauvaise qualité (ça, je l'ai vu), et l'excès de bitrate consommé par la KF est rattrapé sur les autres frames, qui de ce fait perdent  en qualité à leur tour. C'est bien celà ?
 
[oupsss, y avais pas le post de kobaia avant. Pour le coup, ça en deviens indigeste, quoique pertinant.  Avec Kobaia, faut lire en deux passes minimum, et mettre des KF à chaque mot pour piger   ]

[jfdsdjhfuetppo]--Message édité par gURuBoOleZZ--[/jfdsdjhfuetppo]

non, je ne crois pas que tous les réglages disponibles sous Gordian Knot pour le SBC fonctionnent pour le XVID.
Je suis à peu près certain que les paramètres Min et Max pour les KF  ne marchent pas.
 
@Guru, lis ce que Kobaia a écrit, c très intéressant, non on ne peut certainement pas dire qu'une KF est de mauvaise qualité!
Un prog Idm4c basé sur le plugin m4c (pour Divx 3.11 ou Mpeg4 V2) encodait même en KF une deltaframe qui par comparaison était 'mauvaise' et le résultat était plutôt meilleur

 
Adepte de photo, je suis partagé lorsque je vois une KF sous virtual. D'un côté, c'est un vrai damier, aux contours parfaitement défini - tout ce qu'on n'aiment pas voir dans un divX. De l'autre, il semble comporter plus de détails, puisque les autres images moutonnent davantage. La KF ressemble à une photo très fortement compressée en jpeg (le damier est similaire), les autres à des photos compressées en jpeg2000 (tâches floues). Il est vrai que j'observe le phénomène avec une taille de 200%.
Le problème vient de l'enchaînement rapide des KF : macros blocks  trop perceptibles à mon goût : le SBC prend un avantage évident [je rappelle que j'encode avec la dextérité d'un Mr Bean : mes jugements ne portent que sur mon travail, pas sur un codec en général]
 

 
Deltaframe, IPB, GOP, frame difference, indice linéaire.... Je vais finir par exploser avec tout ce que j'ingurgite depuis plusieurs jours.
Y'aurais pas un index français de tous les termes techniques, parce que là, mn Grand Robert de 13.000 pages est vaincu.

OK, la digestion s'actionne...
 
Sinon, mon gros encodage est fini : je vais voir s'il y a moyen d'éviter le paquet de KF sous Xvid grace à un petit vob de 2600 frames dans lequel il se trouve un sacré paquet de KF.

Je persiste et signe : une keyframe doit subir une plus forte "compression" (dans le sens dégradation) car bien que plus grosse que les d-frames, elle ne doit pas provoquer une saute trop importante de bitrate et est donc plus fortement dégradée par le codec (je parle du 3.11, vu que c sur le SBC que je me focalise). En particulier, le DRF est fixe et un chouia plus poussé que pour les delta.
Donc même si l'image est encodée dans son intégralité, elle subit aussi une plus forte compression, en réfléchissant un peu ça semble logique.
Suffit de regarder une kf sans postponing : l'effet blocailleux est plus net que pour les df suivantes qui rajoutent des détails mais floutent le tout. De ce côté là, les KF du DivX 3.11 sont effectivement merdiques, ce qui peut être tweaké avec la technique SBC.
Koepi et un autre mec s'étaient amusés à faire un petit DivX constitué uniquement de KFs : pourrave mais peu d'effets de ghost. Voilà pourquoi il vaut mieux éviter d'insérer trop de KF.
 
Concernant la SCD : idem, la détection de changement de scène avec le SBC suivait le principe que tu as énoncé, à savoir considérer que la scène change à partir d'un certain %age de l'image qui varie (chaque groupe d'images étant analysé, un coeff est affecté à chacune, puis on choisit où insérer la KF s'il y a besoin). Regarde le guide de koepi http://de.geocities.com/de_koepi/n [...] french.pdf aux articles Anti-shit, Span... C'est déjà vieux, il y a eu qq modifs depuis avec NanDub 1.0 qui permet notamment de choisir le DRF des KF.
Pour finir, préciser que comparer DivX et Mpeg-1/2 est pour l'heure un peu ardu, vu que les frames prédictives n'existent pas en DivX : on parle de KF et de Delta frames, c tout pour l'heure...
 
Et en effet, les delta frames qui suivent une KF paraissent meilleures car moins blocky, mais ensuite apparaît un floutage. Gourou Boulet avait raison en comparant les KF au Jpeg, et les DF au Jpeg2000 : le Jpeg conserve bcp de détails mais fait apparaître des blocs, alors que le Jpeg2000 est plus lisse et agréable mais pauvre en détails fins (voir sur le forum Graphisme pour une comparaison et des exemples, pour ceux que ça intéresse)

[jfdsdjhfuetppo]--Message édité par Indiana Jones--[/jfdsdjhfuetppo]

Question subsidiaire : il y a un moyen de faire compter par un soft le nbre de KF ? Ce serais pratique, et m'éviterais de fixer pendant 5 minutes un histogramme bleu et des petites barres rouges.

tu m'impressionnes guru !!!. tu en sais autant que moi en 2 ans . Ca fait quelques semaines que tu t'y es mis si j'ai bien compris??
 
Bon,j'ai pas fait de recherche pousse mais chapeau . Apres le mp3 ,le divx n'aura plus de secret pour toi.
 
 
Ya pas a dire ,tu es mon guru  

T'arrête de te foutre de ma poire !!!
Sérieux, ca fait moins d'une semaine (je suis en vacances, et je passe 16 heures sur ma bécane    en ce moment).
 
Je pense maîtriser 1% de la chose. Quand je réussirait un bon encodage SBC, je serais satisfait. Là, je bataille...

Apparamment, ca marche pas. Inutile d'espérer contrôler l'espacement minimal des KF sous Gordian : j'ai de grosses colonnes rouges qui continuent à apparaître.
Grrrrrr, je suis fâché.
 
Avec quoi je peux éditer un .stat ? Morphix (.log plutôt) ?

nopn,non .Je parle serieusement. Moi aussi,j'aimerais bien maitriser un sbc(surtout pour faire un xvid). Mais je suis decourage par le nbr d'options. Ca m'a foutu un coup au moral et j'ai du mal a me remettre a la tache .

Concernant le m4c, il est aujourd'hui obsolète, Nandub fait un peu mieux:
 
si je me souviens bien, il suit l'algo du PSNR et compare l'image à encodée et celle qui vient d'être encodée; si l'indice du PSNR de chacun sont trop différents (écart paramétrable dans Nandub), alors l'image est recompressée avec un DRF plus bas (elle est donc moins compressée) et ainsi de suite jusqu'au DRF le plus bas (=2) s'il le faut.
 
Le m4c se contentait de remplaçait directement la deltaframe par une keyframe. Je ne sais pas quel système était utilisé pour analyser la qualité de l'image.
 
 
Pour télécharger le m4c:
http://www.divx-digest.com/software/m4c.html
 
 
 
 
Et j'y crois au XviD, ils suivent les spécifications du MPEG-4 (euh, soit tolérant Kobaia, c'est comme cela que je traduit "MPEG-4 ISO compliant" )
 
http://www.xvid.org

 
J'ai jamais dit qu'une KF était plus *petite* qu'une delta-frame ; juste dit qu'elle était plus compressée (d'ailleurs demande à nando ou maras tu verras ce qu'ils en pensent )
Pour reprendre ton exemple : si il y a 10 fois plus d'informations dans une KF que dans une DF, et que cette dite KF est 3, 4 ou 5 fois plus grosse que les images dérivées qui la suivent... c donc qu'il y a eu une compression... or cette compression est sensible dans les KF. Les KF sont limitées en bitrate, et forcer sur le bitrate augmente aussi celui des KF qui à un certain point semblent d'excellente qualité (tu peux pas avoir des KF de 3 Mo non plus...)
 
Concernant l'histoire des P frames, je pense qu'on parle de la même chose mais pas de la même façon. Le DivX utilisé dans un fichier avi doit suivre certaines règles (ce qui est contraignant, ca commence à être admis, cf. l'OGM (lol) et le TMF), notamment la succession KF et éventuellement DF... pour les frames I P B ca reste encore réservé au mpeg "pur".
 
Ensuite, même avec le meilleur paramétrage possible (notamment grâce au SBC), le DivX 3.11 avait tendance à justement défavoriser les KF, ce qui a été amélioré avec NanDub 1.0 (depuis, le DRF et le bitrate alloué (KF boost) ont été laissés à l'appréciation de l'utilisateur). Quant au paramétrage du SBC, je pense m'y être mis assez en profondeur pour connaître les erreurs à éviter (notamment le DRF à 1, garant d'une excellente qualité hi hi hi)

Essayé DivX4log et Morphix 0.71a : rien à faire pour un .stat XviD renommé en .log
Apparament, il faut se satisfaire pour l'heure de la gestion automatisée et unique du codec.
 
Quelqu'un peut me dire en quoi consistent les rares options du XviD (tt se mélange maintenant) :  
 
CBR CONSTANT
 -averaging period : 2000 [par défaut]
 -reaction period : 20
 -up/down ratio : 10

DEBUG :
 -min quantizer : 1
 -max quantizer : 32

C'est la même chose que pour le DivX4.xx. Ces paramètres fonctionnes très bien, n'y touche pas
 
 
Concernant les quantizer, c'est le "taux" maximum et minimum de compression de l'image, plus le nombre est élevé et plus l'image est compressé, donc dégradée.
 
J'ai dernièrement encodé un film sur 1 CD, donc j'ai laissé ces paramètres, mais avec un débit plus élevé, on peut certainement baisser la "compression maximale".

Merci ElShaman. Ce qui me parait étrange, c'est la valeur de 32. 16 est la valeur par défaut du DivX 4 si je ne me trompe.
 
Sinon, par dépit, je me suis amusé à faire des petites compressions mono passes de gde qualité pour mon vob.
En Xvid, j'ai totalisé 142 ou 143 KF
En DivX4, 99 ou 100 KF.
Le fichier final faisait dans les 2 cas 45 MO (pour 105 secondes de vidéo    La qualité est très belle)

Pour info, viens de lire cela sur le forum de doom9
 
http://forum.doom9.org/showthread. [...] genumber=3
 
 
Re: Too many KF  
There seems to be a problem with XviD: with some videos, XviD allows too many keyframes, which look much worse than P-frame, and I didn't find how i can configure this in VDub.
 
What kind of source are you encoding from? XviD's keyframe decision kicks in when more than half of the image changes. I've noticed many keyframes that it misses with this criteria..