Voici les tests que j'ai pu effectuer ce WE, sur le (nouveau ?) patch pour divx 3.11, qui permet de supporter le Variable Key Frame (VKF) positionning (l'appelation est de moi, rien d'officiel ).
 
Le patch est dispo sur divx digest à coté du codec normal divx 3.11.
 
Théorie : le divx actuel est constitué, pour sa partie vidéo,ss
1/ d'un positionnement à interval donné de Keyframe (KF), images clés qui permettent de faire des avance/retour rapides. C'est en quelque sorte des screenshots codés.
2/ Un code divx d'interpolation entre les Key frames =Des delta frames (DF). Une DF est codées en divx et donc plus fortement compressée (pour preuve prenez les stats de vdub).
 
problème : les key ne sont pas forcément bien positionnées ! Si un d'elles se trouve juste avant ou après une rupture, on a donc un enchainement KF/DF défavorable, avec en plus une perte de qualité du fait que les DF sont beaucoup plus compressées.
 
Solution intelligente : disposer les KF aux ruptures, et toutes les XX secondes (comme avant) si pas de rupture.ss
1/ On gagne en qualité => l'interpolation rame moins (ou on peut compresser plus c'est au choix)
2/ On évite les KF "inutiles".
3/ La taille des divx n'est pas très prévisible. De toute façon elle ne l'est plus dès que l'on cropp (ce que je vous encourage à faire, le gain est conséquent), mais comme ici il y aura une taille mini réservée aux KF plus conséquente (et il est logique que les DF soient compressés en fn du débit demandé). Par contre les calculs à la calculette pour faire rentrer pile poil sur 1 ou 2 CD, ben ça va être plus chaud (en fait, le top en la matière serait un programme qui scanne les vob et prédit le débit à appliquer pour telle ou telle taille. Même s'il prend 5-6 heures pour faire son boulot, je suis preneur car je gagnerai un temps fou )
 
En pratique ça donne quoi ?
 
Protocole :
codage sur Matrix (zone 2, PAL) avec Flask (et oui c'est lent mais c'est plus beau alors pas vrai Bruce ? ) avec filtrage "vitesse normale bonne qualité". La taille indiquée est l'image seule. Le cropp est effectué au poil, avec un chti reste de noir en bas. Je vire le générique de fin et une partie du début (quand j'optimise je le fait à fond) avec Vdub. Comme la coupure est positionné sur certaines KF et que celles ci peuvent bouger, j'indique la durée de la vidéo et la taille, ainsi que le ratio.
 
Premiers résultats :
 
Normal, DIVX L 10 100 2000 = 1 418 368 ko pour 123'45s(7425s) soit 191.03 ko/sss
ss(théorique 2000/8*1000/1024 = 244.14 ko/s)
Normal, DIVX L 10 100 1840 = 1 373 544 ko pour 123'45s(7425s) soit 184.99 ko/s (th = 224.61)
 
bon, jusque là rien de bien surprennant. à 2000 on est déjà dans la zone de saturation de qualité : on n'a plus de proportionnalité due au VBR (Variable Bit Rate) qui ramène à une valeur nettement inférieure pour la majorité du film. la différence se fait sur les scènes de combat, particulièrement rapides, où le codec peut monter haut et se faire plaisir.
 
VKF, DIVX L 3 100 1740 = 1 167 678 ko pour 123'41s(7421s) soit 157.35 ko/s (th = 212.4)
 
attention changementS : débit, KF/s ET méthode. <B> Notons quand même que la logique voudrait que j'obtienne avec KF=10 un fichier dans les alentours de 1 298 894 ko soit un gain de 128 Mo ... </B> Ce qui est encore plus apparent avec les débits en lecture : comparez la différence débit effectif et théorique ! plus ils sont différents et plus la compression est efficace (rappelons que le VBR ajuste le débit sur la perte de qualité donc si je lui demande une valeur X et qu'il me sort une valeur eff. beaucoup plus petite c'est qu'il arrive à compresser plus efficacement). On a respectivement les rapports "d'efficacité" (théorique divisé par effectif, + grand mieux c'est) : 1.278, 1.214, 1.349.
Sans commentaire.
 
Peaufinage :
 
mon objectif est 1 309 696 ko donc je recommence. (non par vos beaux yeux, pour les miens ... ). je calcule comme si il y avait proportionalité entre le débit demandé et le débit effectif ( et donc la taille effective).
 
en fait je lis mieux la doc (je fonce assez vite dans le tas ), et je suis les conseils de Dynamite qui me dis d'augmenter le temps mini entre deux KF pour gagner des KF. Je reviens alors à une valeur supérieure à celle recommandée par Bruce (j'ai pas fait les tests de qualité à ce niveau)
 
VKF, DIVX L 15 100 1950 = 1 289 606 ko pour 7720s soit 167.05 ko/s
 
remarquons que les KF ne sont pas placées au même endroit (d'où durée différente). J'ai fait l'encodage sans filtre, et je n'ai eu un gain que de 1.5 frame/s (pour une moyenne de 8fps) pendant l'encodage. <B> Donc sous flask, c'est pas les filtres qui prennent le plus de temps </B> (et sous mpeg2avi ça ira vite également quand il sera apte à les supporter). Notons aussi que l'image, en 720*272 ne cadre plus (une partie du haut et du bas est coupée, l'image est dilatée en hauteur vis à vis du vob) : j'avais décoché "conserver rapport H/L". Remarquez au passage le format bizarre 2.65:1 ... je vais creuser ça moi, car sous le rippack j'ai fait des fichiers de 720*304 et pourtant ça semble correct à première vue ...
 
si j'avais eu proportionnalité j'aurai du tomber sur la valeur visée. En fait je l'ai ratée de 20 090 ko. Et sans compter le fait que j'ai du bruit dû à l'absense de filtre. je vais donc recommencer en forçant la dose puisque je dois avoir dépassé la zone linéaire :ss
 
VKF, DIVX L 15 100 2080 = 1 340 342 ko pour 7423s et sans filtre.
 
bon là c'est un peu trop (30Mo de +) mais je pense que vous avez pu voir, qu'avec le codec normal l'excés est encore plus important avec un débit de 1840 !! <B> Donc je gagne facilement 250 à 300 kbit/s en débit en utilisant cette modification ! Et je pense que le gain est aussi fort pour les fortes compressions (si vous pouvez tester c'est pas de refus !) </B>
 
Au niveau de la qualité, tous les fichiers sont très acceptables. Je peux pas trop me prononcer car je regarde pas suffisamment le film. A propos, existe t'il des softs permettant des mesures fiables, quantitatives (style écart quadratique moyen par pixel entre une image de vob et une image divx ?) comme il en existe pour le mp3 ?
 
ajout supplémentaire (je vais finir par y arriver ) : j'ai encodé à 2000 mais cette fois avec le filtre HQ bicubique. Je voulais surtout obtenir la meilleure qualité possible. Et je me suis fait couillonné : comme le filtre vire du bruit, la compression est encore plus efficace.
 
VKF, DIVX L 15 100 2000 = 1 145 536 ko pour 7423s et HQ bicubique/ keep aspect ratio.
 
<B>parenthése sur le gain apporté par le filtre Flask : les facteurs "d'efficacité" (cf ci dessus) des deux derniers essais sont de 1,406 et de 1,582. Sans appel. Gain d'efficacité de 12.5 %.</B> (et également prise de tête, j'y arriverai jamais ... 8H de compression la dernière fois ... ) Au niveau qualité, je vois pas la différence avec le vob sur mon vieil écran 17". (ah si ! quand il est sur l'hélico et qu'il tire à la cataline, il y a deux pixels qui sont pas pareils )
 
Putain ! que dire lorsque qu'on aura les filtres VHS anti bruit j'imagine déjà les divx plus beaux que les dvd
 
Voili voilu. Plus on testera de méthodes différentes ou de softs et plus on avancera pour obtenir the best quality.
 
--------------------------------
> Bruce : teste aussi et inclus le dans le pak si tu vois une amélioration (tu peux le faire avec mpeg2avi, ça donnera un double avis). cf commentaire de Dynamite.
--------------------------------
Notez aussi qu'il faut essayer de faire des mesures comparatives (ce qui n'est pas tout à fait le cas ci dessus), et que par exemple on n'a pas la même taille de sortie selon qu'on utilise Mpeg2avi et Flask. Exemple après avoir fait une version rippack optimisée, et "adaptation" sous flask :
 
MPEG2AVI : 1 303 339 ko, débit 2000 et taille effective 720*354
Flaskssss: 1 418 368 ko, débit 2000 et taille effective 720*272
 
comme la taille d'image pour flask est plus petite, le fichier devrait être plus petit ... Je préfère raisonner sur des fichiers avi de taille comparable plutôt qu'en terme de débit. La différence ne doit pas venir des filtres (au contraire !), mais du concept de VBR de chacun d'eux.ss
(et les calculettes divx font comment ? à partir de quelle source ?)
--------------------------------
 
Toujours là ?? . Si vous avez des questions, j'essayerai d'y répondre si je peux me connecter (je finis mes cours/interros mardi midi et ne commence mon stage que lundi 5fev, et encore faut-il qu'ils m'aient gardé mon login là bas ... )
 
Bon ben je vous laisse, j'ai plus de six films qui attendent sur le dur, alors faut que j'y aille Putain, me faut un deuxième ordi ! Je vais m'attaquer au record de 2400 sur Men In Black !
 
PS Special Thanks to Bruce, son guide et aux balèzes du forum. Trois semaines de pratique pour atteindre mon niveau de compréhension, c'est grâce à vous !!

ajout supplémentaire : matrix 2286 ok, leger overburn en vue mais 2286 et avec flask ss:cool:

merde les gras ne passe pas, il ont changé les tags vis à vis des pages que j'avais sauvegardé ... bon je vais pas modifier et reposter, c'est assez long comme ça. désoléss:sweat:

Hé bé, c un roman que tu mous pond là
 
Bon, j'ai pas tout lus en détail mais juste survolé, je regarde ça au calme ce soir

Euh en gros tu nous fait un resumé net et clair de ce qu'il vaut mieux faire Atlantis ?

Ehh, s'il faut encoder 10fois pour avoir la bonne taille quel est l'interet???
 
Perso je prefere etre sur de la taille que ca va prendre et pour ca le MakeFilm rulez...
 
Donc tant que phreak404 ne sort pas son m4c qui s'annonce bien je reste avec le codec normal et MakeFilm (du moins pour les films de moins de 2h)...
(a propos Bruce comme tu comptes te mettre à la programmation de mpeg2avi j'espere que tu suis l'interessante discution qui a lieu
la:
http://pub28.ezboard.com/fdoom9smp [...] =475.topic )

dis GodFearMe (vraiment ?) ou est-ce que je peut suivre les nouvelles sur M4C ?

bon je crois que j'ai trouvé. 'Tain c'est des monstres les types qui discutent sur ce forum...

Il y a quelque chose ke je ne comprends pas !!
Pourkoi tu fixe KF a 10 ou a 15 si tu utilise justement le Variable Key Frame (VKF) positionning ???
 
En outre ou puis je trouver la doc dont tu parle et aussi les conseils que prodigue Dynamite ???
 
Et pourquoi pas augmenter le nombre de KF ???
 
Merci et A+

Arf, il est trop tard pour que je lise tout ça
 
Bon, désolé, je lis ça demain (serieux !)

ça se comprends, c'est un peu lourd
 
http://www.divx-digest.net/softwar [...] h.v1.0.exe
 
et j'ai pas testé http://www.divx-digest.net/softwar [...] x_322b.zip
 
qqn peut tester sur mpeg2avi + forte compression et comparer avec ce qu'il a déjà obtenu en temps normal ?
 
>GodFearsMe : nickel le lien. je vais me faire plaisir ...
 

flask + keep aspect ratio + HQ bicubique + patch. dorénavant je ne ferais plus que ça

ben pour pouvoir faire des avances/retour si pas de rupture. Dynamite propose 99999 s . c'est un trop pour moi
 

ben de tester. et puis >2H en 2286 avec deux sons divx64kb + soustitre sur deux CD700 c'est cool ... Au moins je sais que j'aurai plus JAMAIS à les refaire. parce que divx2 et 3ivx c'est pas pour demain qu'on aura une amélioration fulgurante (remarque je ne demande que ça moi )

bon appellation officielle VKIssss
merci Slyde pour le lien.
 
vais tester m4c (enfin si j'ai le tempsss:pt1cable: )

Ayé ! G lus !
 
Bon, le VKI peut se trouver en deux formes. Soit il est implémenté au niveau des codec (les fameux 3.20 et 3.22...), soit il est implémenté au niveau de l'encodeur (m4c, Mpeg2aviAR...).
 
J'avais essayé le VKI au niveau du codec et j'ai été assez déçus, ça n'apporte pas grand choses car le codec réagit assez mal en réalité et met parfois trop de KF.
D'ailleur, pour la petite histoire, le VKI était inclus dans le codec DivX depuis longtemps mais jamais activé... Devinez pourquoi ! (même M$ ne l'active pas...).
 
Par contre depuis peu il y as les encodeur VKI. Il FAUT alors utilise le codec "normal" (3.11) pour que ça marche (sinon merci le merdier !). Ces encodeur eux apportent une vraie amélioration à la qualité. La dernière version du m4c (icem4c) est d'ailleur assez intéressante à ce niveau.
 
Le source de mpeg2aviAR étant dispo je vais essayer de l'intégrer au mpeg2avi "normal" (cf le thread sur mpeg2avi 0.0.7).

Salut,
 
Atlantis, tu parles de VBR, ou VKI, peut importe l'appellation, comme du dispositif du meme nom utilise en MP3.
 
Je suis pas trop d'accord avec cette vision des choses.
 
Le changement apporte par le patch ci dessous : http://www.divx-digest.net/softwar [...] v1.0.exess
ne sert pas forcement a adapter directement le debit de l'encodage, meme si son utilisation fait varier un peu la taille des .avi obtenus.
 
Concernant le VBR du MP3, ce mode d'encodage consiste a pouvoir changer a chaque trame (frame) MP3 le nombre de bits utilises pour coder la trameen question. Les trames MP3 etant a un rythme fixe, utiliser plus de bits pour coder une trame revient a augmenter le debit, reduire le nombre de bits reduit le debit...
Le principe VBR est donc de regarder pour chaque trame si la perte de qualite apres encodage est importante, et au dela d'un certain seuil de differences, on augmente le nombre de bits alloues a la trame pour avoir une meilleure similitude. Inversement si une trame encodee depasse un certain seuil de similitude, le codage est "trop bon" et on decide de reduire le nombre de bits alloues a cette trame pour recuperer des bits et donc du debit. Voila pour le MP3, maile moi pour plus de details.
 
Concernant le Scene Detect Patch, c'est tres different. Le compression DivX;-) est, comme le mpeg 2 mais avec des extentions, basee sur 2 principes :
1_ La redondance spatialess
2_ La redondance temporelle
La premiere considere que sur une image FIXE, toute l'information n'est pas utile. Pas exemple, si tu prend une image d'une vache dans un champ, toute la zone du ciel est bleue, la prairie est uniforne, il suffit de coder la vache precisement et deux zones, le ciel et la prairie pour simplifier, donc pas la peine de coder tous les pixels, autant directement dire que toute une zone est bleue, qu'une autre est verte, et qu'on a une image precise a caser au milieu (la meuhmeuh). Ca c'est le travail typique d'une compression JPEG. On peut tres bien imaginer une compression video qui n'optimise que la redondance spatiale, ca existe, ce n'est pas le plus efficace, ca s'appelle du MJPEG (Motion - Joint Picture Expert Group), mais c'est encore utilise dans les milieux pro pour certains avantages (scrolling immediat, qualite pas mal du tout...) .
La seconde concerne le fait que les images qui s'enchainent sont rarement decorrellees les unes des autres. Typiquement si on reprend la scene de la vache qui se ballade dans un champ, d'une image a l'autre peu de choses changent, du coup, on ne va pas recompresser toute l'image selon sa redondance spatiale, mais on va coder la seconde image en ne donnant que les differences par rapport a l'image precedente. C'est tres efficace, surtout si on met un peu d'intelligence dans le codage de cette difference. Par contre, pour voir l'image 2, on a besoin de decoder l'image 1 en entier, puis d'appliquer la difference pour obtenir l'image 2.
La compression resultante est tres importante, mais n'est efficace que si seulement une partie de l'image change.
 
On applique donc ces deux principes au codage DivX;-). On ne code que certaines images en entier (les trames intra, ou KEY Frames), les autres sont obtenues en realisant un codage differentiel (trames inter) .
 
Donc jusqu'au patch en question, le critere pour placer une key frame etait temporel, c'est a dire qu'on placait une key frame toutes les n secondes, typiquement toutes les dix secondes. A 25 images seconde, cela signifie que tu as une image codee en entier, et ensuite tu as 249 images qui sont calculees par difference avec la premiere. Si la scene change beaucoup, un certain debit etant alloue pour coder les differences, la qualitess de la sequence va baisser, les differences etant importantes.
 
Le patch modifie ce critere d'insertion d'une key frame. Il continue a inserer des key frames a intervalles reguliers, mais en plus il realise une detection de changement de scene. Si la scene change (on passe de la vue d'une vache paisible dans un champ a celle d'une ville par exemple) le patch insere a cet endroit une key frame. Le critere de placement des key frames est donc plus optimise, car typiquement l'insertion d'une key frame genere une augmentation locale du debit.ss
Donc inutile de placer une key frame la ou une trame inter saurait coder tres bien la difference.
 
Pour utiliser le patch correctement, il faut donc augmenter l'intervalle temporel regulier entre 2 key frame (L'extreme cas est de fixer cet intervalle a 9999s comme le suggere Dynamite), et laisser le patch placer tout seul comme un grand ses key frames la ou il faut.
 
Maintenant, en pratique, ca donne des compressions de meilleure qualite , et ca peu reduire le debit donc la taille du film, mais ca, ca depend du film en question. Ce qui est sur, c'est que la qualite augmente, mais par contre les aleas de debit sont plus importants, du coup il faut prendre un peu plus de marge. Mais en aucun cas on ne peut parler de VBR, on ne joue pas sur le debit pour ameliorer la compression, ce n'est au'une consequence...
 
J'ai teste le patch sur Sleepy Hollow, l'augmentation de qualite est tres sensible, surtout les scenes avec des eclairs. J'ai remarque qu'en plus ca faisait baisser un peu le debit, en reglage je mets 30 s pour les intervalles key frames (au dela la navigation au curseur est vraiment penible)
 
Voila, j'espere avoir un peu eclaire le sujet. Plus de details par mail si tu veux, difficile de penser a tout et de tout dire dans un seul post.
 
A +

Voilà qui est clair ManuLM
 
Essaye qd même le VKI au niveau encodeur (et non codec), c'est radical !
 
(au passage, le DivX EST VBR !!!).

Bien sur, le DivX est VBR par nature mais ca n'a rien a voir avec la detection de changement de scene.
Je voulais pas en parler pour ne pas embrouiller le le topic
A +
 
PS : Bruce, Bravo pour ton rippack V2, ca c'est du boulot !
En plus ca va faire plaisir a NicoO (cf topic sur 1 ou 10 KF )
 

--Message édité par ManuLM--

[quote]J'ai teste le patch sur Sleepy Hollow, l'augmentation de qualite est tres sensible, surtout les scenes avec des eclairs. J'ai remarque qu'en plus ca faisait baisser un peu le debit, en reglage je mets 30 s pour les intervalles key frames (au dela la navigation au curseur est vraiment penible) [quote]
 
pour le reste d'acc mais je pensais m'adresser aux initiés donc pas tout détailler
rq : une key a une taille assez peu variable. Une delta après une rupture est énorme ! c'est là que le gain se fait.
rq2 : fans mon texte, il y a plein de choses. ne pas confondre VBR et VKI (=VKF dans mon texte ci dessus)
 
ok pour sleepy hollow. avec mpeg2avi tu l'as fait ?
 
> bruce : ah bon pas d'amélioration sensible ? vais tenter m4c mais perso déjà avec le patch l'amélioration est conséquente. Men in Black en 2400 sans couper tout le générique (et avec deux langues+soustitres) donc c'est kif-kif divx-z !!
Quand tu tires les stats d'un avi sous vdub, tu compares la taille que prennent les key et la taille que prennent les delta, ainsi que la taille moyenne des key et des delta : tu va voir que si VKI alors taille moy. delta baisse très sensiblement. Et même s'il en génére un paquet ... le total occupé par les key à CHAQUE rupture est la taille mini incompressible pour un film (à moins se faire les key en wavelets mais on en est pas là )
 
bon je vais continuer mes tests ...

Pour Sleepy Hollow, le test je l'ai fait avec mpeg2avi, DivX 3.11 et le patch en question ...
 
Et je suis pas forcement d'accord avec toi Bruce, pour moi le patch fonctionne assez bien. En effet, la scene du debut avec les eclairs est parfaite pour ce genre de test, et justement dans ce cas le patch fonctionne carrement bien. La difference de qualite avec la verison non patchee est vraiment significative. Maintenant je n'ai pas encore teste les encodeurs VKF. D'ailleurs, si vous avec des url interessantes pour ca, ca m'interesse ...
 
Au fait, j'encode en low motion, a 860 kbit/s de souvenir (le film passe pile poil sur CD dans cette config) avec le son normalise puis passe en MP3 96 Kbit/s.ss
 
A +

ManuLM et Atlantis > Vous suggerez d utilisez quel reglage pour les KF lorsque on utilise "DivX.Scene-Detect.Patch.v1.0" ???
La resolution change t elle quelque chose au gain apporte par ce patch ???

Pour les KF, si tu n'en as rien a foutre de la navigation dans ton DivX, prends qquechose de grand comme 30s ou plus si tu veux. D'ailleurs, il y a un long post anime sur la frequence des KF, tres interessant :
http://forum.hardware.fr/sqlforum/ [...] config.inc
 
En ce qui concerne la resolution, c'est un autre probleme. Pour ca, Bruce a lance ces jours ci un post sur le sujet qui tourne pas mal (bon, ils se sont un peu engueules dessus , mais au final, la resolution qui ressort du post est du 512*xxx selon le format de ton film)
Le post est la :
http://forum.hardware.fr/sqlforum/ [...] config.inc
 
Sinon, pour repondre a ta question, oui, meme avec le patch tu as interet a reduire la resolution comme je te le dis plus haut, mais c'est decorelle du fait que tu utilises le patch de detection de changement de scene.
 
A+

--Message édité par ManuLM--

juste un petit test pour verifier que c'est bien a 20 que le dossier s'enflamme

--Message édité par ManuLM--

Ben non ss
 
Bizarre ca !!

Ahhhhhhhhhhhhhhh
 
:lol::lol::lol::lol:

ajout complémentaire détermination taille avec VKI
bon faut faire au moins un encodage mais après c'est gateau
faut éditer l'avi produit avec vdub et demander les info.
 
notez la taille prise par les KF. Elle ne change quasiment pas avec le débit demandé. c'est donc un "offset" comme on dit
 
par contre la taille des delta frames est proportionelle au débit demandé : une petite calculette et vous pouvez (prévoyez quand même 5 Mo de marge on sait jamais ) lancez votre votre encodage optimisé pour rentrer sur deux cd.
 
au fait bruce, 41Mo de KF sur "Anna et le Roi" croppé, c'est pas la mort !! et m4c faut déjà avoir un avi donc perte de qualité par decodage/encodage.
 
more to come ... enfin si j'ai le temps, ils ont hyper grattiné mon stage (j'aurai pas du blaster le premier aussi )

->Atlantis
 
Il ne faut pas avoir un avi avec m4c, un avi virtuel suffit
(DVD2AVI->VFAPICONV->VIRTUALDUB->M4C en ligne de commande)
Donc aucune de perte de qualité

Ou encore :
DVD2AVI > AVIUtil > VFAPICONV > ICEM4C...

ouais et pour chainer vous avez pas un petit *.bat sous la main (mail svp) à me passer pour que je m'amuse moi aussi ?

Non, pas de bat possible, les softs sont tous sous win et pas controlables via des scripts (hormis vdub).

ben je veux bien mais comment les enchainer alors ?? (ton rippack 2.1 le fait pas encore si ?). ça me fait chier de savoir que j'ai sur le dur des softs puissants mais que j'ai pas le temps pour surfer aller chopper le mode d'emploi "réel" qqpart...

euh je sais je suis chiant mais je trouve pas VFAPICONV      
 
ni sur http://www.digital-digest.com/ ni http://go.to/doom9

Tu n'as pas du bien regarder
 
http://doom9.org/Software/mpg/VFAPIConv-1.04-EN.zip

Il y en a parmi vous qui ont essaye le vdub de nando ???
Les resultats sont surprenants !!!

bon alors j'ai tester la méthode "DVD2AVI > VFAPICONV > AVIUtil > ICEM4C..." tout marche bien jusqu'à la fin où il me met un "error sys dans lm4c_output.auo" vous savez d'où ça vient ?
vais tester l'enchainement proposé par Bruce.
 
qu'est ce qu'il apporte le vdub ci dessus ?