Reprise du message précédent :

 
Certes mais c'est aussi le MPEG4 (DivX et Xvid en particulier) donc la qualité est aussi importante que la vitesse Cela explique l'utilisation du Xvid (codec très prometteur amha) dans le premier test (non reproductible avec Vidomi) et la méthode utilisée. Si je ne veux que la vitesse je fais du MJPEG  

CODEC = CODEUR/DECODEUR.

je n'ai pas utilisé de CODEC SMP mais un soft optimisé SMP qui se sert d'un encodeur ou codeur ou codec (comme tu veux) appelé DivX (Xmpeg)
 

J'ai vu et noté pour vidomi.
XIS n'est pas soit disant SMP, il est SMP.
Il n'y a pas jeu egal, puisque qu'il ne sagit pas du meme proc ni du meme soft, il faudrait tester vidomi sur un Bi-P3 ou xmpeg sur un Bi-AMD pour le savoir, tu ne dois pas être habitué a le demarche scientifique toi. Etrange pour quelqu'un qui travail dans un labo.

Bonne idée
Vous pouvez pas lui refiler une bonne grippe ou une gastro?

[edtdd]--Message édité par kroll33--[/edtdd]

SI SI SI
Les tests "single Cpu et BiCpu" ont été fait sur la MEME machine.
Les affinités (gestionnaire des tâches) ça existe !!!
 
Donc ne mets pas, stp, en cause notre démarche scientifique.
 
Tout a été testé sur UNE SEULE ET UNIQUE machine avec les MEMES paramêtres pour CHAQUE encodage...

[edtdd]--Message édité par jotenakis--[/edtdd]

 
c'est pas facile t'es pas clair
 
et puis je fais pas que ça (comme quoi le cerveau est smp lui   )

[edtdd]--Message édité par tg0021--[/edtdd]

-Je suis venu car j'ai vu SMP, c'est assez rare et les echanges sont assez rare pour être noté.
Je n'ai pas fait gaffe qu'il sagisait aussi d'un echange sur le Xvid.
 
-Pour le multithread, si c'est bien fait et parralelisé on gagne de la vitesse et on peux dire que c'est optimisé pour le SMP, si c'est monoprocess on ne gagne rien (exemple des soft de lecture divx).
 
- pour utiliser le SMP il faut fair des processe paralelisé et pas en serie, ça n'a rien a voir avec une gestion par l'OS ou l'appli.
Dans l'exemple de Vdub, le codage est peut être fait par un proc , et l'autre proc fait l'ecriture sur le disque ou l'affichage ou autres.... c'est pour ça que je disais que ce n'ai pas reproductible. Car ça depend du drivers de disque, du disque dur, de la carte video, de son drivers etc....
Bref plein de trucs qui ne sont pas dependant de l'appli qu'on veux tester.

Si si si quoi

Ca je m'en doute.
Ce que je veux dire, c'est que maintenant on sait qu'on obtiens +XX% avec vdub entre un AMD et un Bi-AMD.
OK.
Mais est ce que c'est aussi +XX% avec un Bi-P3 ????
Et est ce pareil avec des soft optimisés pour ???

J'avais cru comprendre que tu comparais aux +XX% que j'obtenais avec XIS sur Bi-P3 que tu declarais que c'etait jeux égal.
Tel quel, sans autre element de comparaison, ça on ne peux pas encore le dire.
Je ressayerais ce soir avec vdub pour voir.
La derniere fois que j'avais essayé ça avait donné a peine +10%

C'est exacte, je m'exprime mal.
Veuillez accepter toutes mes excuses.

 
Libre à toi de t'y mettre, mais a priori si c'est une question d'optimisation SSE (y'a pas de SSE2 dans les p3), je te rappelle que les athlon MP/XP dispose des instructions SSE. Le gain relatif ne devrait pas être énorme.
 

 
Merci pour cette démarche constructive n'oublies pas STP de préciser ta config.
 
Pour faire plaisir à tous le monde, avec jotenakis, on est en train de faire un test XMPEG 4.2a en bi-cpu et mono-CPU (avec les mêmes paramètres que VDUB et Vidomi). Tant pis on se fera engueuler par nos chefs. A suivre donc...

[edtdd]--Message édité par tg0021--[/edtdd]

Haaaa..
Super cool les gars...
n'oublier pas d'indiquer le idct utilisé.
Le plus rapide/stable est normalement le "optimised MMX" meme sur un AMD.
 
Ca y est, votre bosse a choppé une grippe jusqu'a la fin de la semaine?
 
Pour ce qui est de la comparaison AMD - P3  
Un Mono AMD 1.4Ghz va à peine plus vite qu'un bi-P3@960 (diff de 2 à 4 fps)
Meme idct(optimized MMX), meme methode(video uniquement), meme codec(4.12), meme soft(XIS).

-DivX 4.12 2pass@1600Kbp
 
c'est pas mal comme b/r : mais pas plus de 2h00 sur 2CD de 700
 
-Miha's Reference IDTc
 
c'est hyper lent (si si je viens de tester) et à l'époque les codeurs de Flask le déconseillait fortement !
 
-720x576 croppé à 720x576
 
ben c'est pas croppé ça !
 
-Filtrage SSE Bicubic
tu veux parler du resize là : ben c'est bizarre 2 lignes plus haut du dit que ta resolution de sortie c'est du 720x576 donc pas de resize. En plus le bicubic c'est le plus lent.
 
-YUV12 pour la conversion du format de couleur
 
bon, alors en conclusion, tu veux que je gobe qu'en utilisant tous les algo les plus lents (Miha's ref MMC IDCT, resize bicubic, preview lors de l'encodage) sur un bi-MP 1.2 tu fais 65 fps ???????
 
Dis c'est bon ce que tu fumes, tu paut nous en faire profiter !!!

Test mono/bi-cpu : XMPEG 4.2a  (SMP)
Vob : 19 min 56 sec (la momie)
bitrate : 703 kb/s
resize : bilinear (sur le premier post c'était du bicubic)
resolution : 576*256
Format YUY2.
IDCT : DVD2AVI MMX (semble être le plus rapide)
no audio
 
1 CPU (Athlon MP 1800+) : 33 fps (cela confirme le test de Slyde sur MPEG4-fr, XMPEG4.2a avec un resize bilinear est le plus rapide en mono-proc)
 

 
2 CPU (2*Athlon MP 1800+) : 43 fps avec conso proc 75%
 

 
Soit, si je ne m'abuse un gain de 30 %
 
 
Rappel des épisodes précédents :
Paramètres sinon identiques au moins très similaires
-------- Vidomi (SMP) -------------
1 CPU : 31.5 fps
2 CPU : 46 fps avec conso proc 100%
soit un gain de 45%
 
-------- Avisynth + VDub (non-SMP) -------------
1 CPU : 31 fps
2 CPU : 48 fps avec conso proc 85%  
soit un gain de 55%
 
Voilà, maintenant nous on conclut pas, mais alors pourquoi un soft non SMP fait aussi bien que deux softs SMP.
 
Ptet une piste : le nombre de threads -> VDub (7), Vidomi(6), XMPEG(5)  ???
 
TG et Jotenakis

[edtdd]--Message édité par tg0021--[/edtdd]

Merci pour le test.
Très sympa à toi.
Je m'interroge, comme toi, sur les differents resultats qui vont à l'inverse de l'apriori.
 
J'essaye ce soir avec "dvd2avi MMX" sur bi-p3

 
Au vu de ton post précédent, on a refais le même test en Xmpeg mais avec l'IDCT OPTIMIZED MMX. C'est un peu mieux : 1 fps en +.
 
Merci à tout le monde d'accorder du crédit à ce que l'on fait. C'est fait avec intransigeance : on ne veux rien prouver quant à la qualité des softs.

[edtdd]--Message édité par jotenakis--[/edtdd]

jotenakis a écrit a écrit :     en moyenne ou en crête ?     En tout cas c'est plus intéressant que le débat "T'es nul, t'es une merde... gnangnangnan ... cours de récréation"   Pfff

 
constant, a 2% de variation pres

petite precision
rien que d'utiliser avisynth et virtualdub (ou nandub)
ca optimise en smp
regardes dans le gestionaire de taches, virtualdub a plusieurs threads, donc automatiquement windows repartit la tache du mieux qu'il peut
d'un cote, le decodage mpeg2+resize pour le thread avisynth
de l'autre, l'encodage
 
 
mais comme la partie encodage demande plus de puissance, elle doit attendre l'autre thread, d'ou le fait qu'on attends pas les 100% de charge

[edtdd]--Message édité par Bricolo--[/edtdd]

 
Merci pour cette explication. On pensait effectivement à quelque chose du genre thread d'encodage et thread de resize pour expliquer ces résultats (multi-threading).
 
Nous avons effectivement constaté que VDub a 7 threads durant l'encodage.
 
Cela nous semblait plus vraisemblable que de l'écriture sur le disque (en UDMA5 avec un débit de quques ko/s pour écrire l'avi) ou toute autre opération annexe sur l'OS. Un thread de calcul est la seule explication possible.
 
Je vais effectivement creuser du côté d'Avisynth.

[edtdd]--Message édité par tg0021--[/edtdd]

je viens de faire une serie de test sur Bi-P3 à l'aide de Xmpeg4.2a
Le gain varie de +30% à +53% suivant l'idct et le filtrage utilisé.
je vais mettre les resutats en mode teste des fois que je merde avec les liens sur images.
Donc j'ai pris les meme parametre que toi sur le Bi-AMD puis les parametres qui me donne la meilleur vitesse (grosse difference).
 
--------------------------------
P3 960
700kb/s
700 kb/s
Filtrage: bilinear MMX
576*256
YUY2
IDCT: DVD2AVI MMX
1CPU 15.6 fps
2CPU 20.0 fps
+30%
--------------------------------
P3 960
700kb/s
700 kb/s
Filtrage: bressenham
576*256
YV12
IDCT: DVD2AVI SSEMMX
1CPU 17.1 fps
2CPU 26.2 fps
+53%
----------------------------------
Ca complique un peut, mais on retrouve bien les +30% avec la meme configuration que se soit sur bi-P3 ou Bi-AMD.
 
La difference est assez halucinante, ça passe de +30% à +53%
Je n'avais jamais essayé DVD2AVI SSEMMX avant, avec optimised MMX ça va moins vite.
Le deuxieme test est le plus rapide que j'ai pu faire, tout changement idct/formatUY/filtrage donne une vitesse inferieure.
 
Vous avez une explication sur cet etat de fait?
Il n'y a pas plus de tread suivant les cas.
Est ce l'utilisation SSE et MMX qui se parralelise mieux ?
En tout cas ça montre bien l'importance de tout les parametre quand on veut tester un truc (je dis ça pour ceux qui dise que flask est lent )
 
Ca vaut peut être le coup d'essayer d'autres parametres dans vdub et vidomi des fois que....

[edtdd]--Message édité par kroll33--[/edtdd]

Moi,j'utilise xmpeg 4.2a de temps en temps . Et je reaffirme que ce soft n'est pas stable du tout . Il plante tres souvent. (meme si ca deplait a poussin magique).Et ma machine est tres tres stable . Desole . DEs fois ,il me suffit d'ouvrir la fenetre de parametres ,de changer qques parametres,de faire ok ,et crack ,Flask ds la choucroute.
 
rippack ne plante jamais, dvd2avi jamais ,vdub+ Gknpt jamais sur ma machine . Donc je le redis ,le dernier flask est un tres bon soft mais il plante comme une grosse truie

les photos.
Bi P3-960
les parametres sont dans le post au dessus
 
 
meme config que sur AMD 1CPU

 
meme config que sur AMD 2CPU : +30%

 
meilleur config possible 1CPU

 
meilleur config possible 2CPU : +53%

 
Ca a du bon ce genre de test, je viens de trouver un idct plus performant que ce que j'utilisais avant

[edtdd]--Message édité par kroll33--[/edtdd]

Le seul moyen que j'ai trouvé pour planter Xmpeg, c'est de mettre une valeur NEGATIVE dans les valeur de rezise/crop.
Quelque fois le rezise automatique bug et met une valeur negative, faut juste regarder et faire attention.

non,non,meme si je fais un rezize manuel en positif ,c'est pareil . Le nombre de gens chez qui ca plante ,c'est ultra connu . Meme le createur de la version,c'est un italien le dit.ALors quand meme .

[edtdd]--Message édité par chris25fr--[/edtdd]

 
je sais pas sur mon P3 o/c a son max j'ai jamais de pb avec xmpeg..
sauf quand j'ai installé des codec comme un porc (genre 4 codec MP3 différent...)
bah la faut pas cherché a encodé le son en meme temps que la video cé tout

je n'encode jamais le son avec flask.

La je suis d'accord avec toi, c'est pas top du tout, et en plus ça bouffe des fps
Pour Xmpeg, il y a des machine sur lesquel je n'ai jamais reussi à le lancer, a par ça, quand ça marche ben pas de probleme par la suite que se soit sur mon AMD/Win98 ou le Bi-P3/W2K.
 
Bon, si on revenais au SMP.
Apparement que se soit Bi-P3 ou Bi-AMD le gain en % est le meme, bonne nouvelle non?
Quelqu'un a t'il fait d'autres test?

 
Comme je le disais plus haut les instructions MMX et SSE sont communes aux P3 et aux AthlonXP donc ça ne m'étonne pas. Merci d'avoir confirmé  
 
 

Nan mais utilisé vos AthlonXP en Enhanced 3DNow!... c'est plus rapide que les SSE sur ce CPU...
 
Mais de toutes facons le Bi-AMD devrais avoir un meilleur gain... Vu l'architecture...
 
Le mieux serais de voir un Bi-Xeon normallement le gain devrais etre bien meilleur

Meme sur un AMD 1.4, MMX est plus rapide que 3dnow.

On vient juste de mettre en evidence que le gain est le même que se soit un bi-P3 ou un Bi-AMD.
30% pour le test en question, et je suis persuadé qu'on aurait aussi +53% avec un Bi-AMD si on utilise les memes parametres (SSE et MMX)

Non, c'est pareil, du moins avec les Xeon basé sur le P3
Je n'ai pu tester qu'au boulot que sur un petit VOB et NT4 (pas de lecteur de DVD) le gain pour le 2eme proc etait comme avec le P3.

Bah alors c'est que c'est pas du vrai bon SMP vos applis.
 
 
Les instructions MMX et 3DNow! ne sont pas equivalentes.
Les Enhanced 3DNow! sont moins évoluées que les SSE.
Mais l'Athlon XP est mieux optimisé en Enhanced 3DNow! qu'en SSE.

Je suis satisfait de la nouvelle tournure que prends le débat et te remercie Kroll33 pour tes tests.
 
As tu essayé sur ton bi-proc, la méthode avisynth-vdub pour voir si tu retrouves les mêmes (à peu près) gains que nous ???
 
Très content qu'on ai pu te montrer (par un pur hasard, en fait) un meilleur IDCT que celui que tu utilisais jusqu'ici
 
Pour chris25fr : tentons de sortir du débat "Xmpeg est pourri", que j'ai, j'avoue, mais sans le vouloir, provoqué. Ici, on veut juste "s'amuser" à voir les gains SMP avec différentes méthodes...
 
   

[edtdd]--Message édité par jotenakis--[/edtdd]

>Meme sur un AMD 1.4, MMX est plus rapide que 3dnow.
C'est ce qui est généralement dit. D'ailleurs en ce qui concenrne les optimisations du codec DivX, il semble que les instructions intel (SEE et surtout SSE2) soit plus interessantes que 3Dnow et 3Dnow+
 
>Mais de toutes facons le Bi-AMD devrais avoir un meilleur gain... Vu l'architecture...
Je ne voulais pas le dire pour ne pas faire naître une polémique (une de plus) stérile sur les perfos AMD vs. Intel. De nombreux tests montrent que l'archi AMD est plus performante (à fréquence égale) sur l'encodage DivX. C'est quantifiable facilement en mono proc, en bi-proc je ne suis pas sûr que le gain soit linéaire
 
>On vient juste de mettre en evidence que le gain est le même que se soit un bi-P3 ou un Bi-AMD.
On pourrait trouver des arguments dans les deux sens. Là je ne me mouillerais pas...
 
 
>je suis persuadé qu'on aurait aussi +53% avec un Bi-AMD si on utilise les memes parametres (SSE et MMX)
Faut avouer que c'est assez obscures ces différentes méthodes dans Flask. Rares sont les encodeurs qui font explicitement références (Miha...) à ces méthodes. Peut-être que Bruce et/ou Blacksunsoft et/ou Slyde pourrait nous éclairer...
 
>Non, c'est pareil, du moins avec les Xeon basé sur le P3
Je n'ai pu tester qu'au boulot que sur un petit VOB et NT4 (pas de lecteur de DVD) le gain pour le 2eme proc etait comme avec le P3.
 
Bizarre car la memoire cache n'est pas identique (quantité, vitesse peut-être je ne m'en souvient plus) et c'est une des explications pour les perfo des proc AMD. Le gain semble donc être linéaire. Interessant tout ça...
 
@ demain

[edtdd]--Message édité par tg0021--[/edtdd]

 
On n'a jamais dit que c'était du vrai bon SMP et c'est pas NOS applis... Malheureusement je ne suis pas l'auteur de GKnot.
 
       
 
Je ne pressens que trop la difficulté d'écrire des codes parallélisés pour porter un jugement : non, juste un constat !!!
 
On veut juste voir...

mais je m'interrese quand meme de tres pres a flask parce qu'il a plein de qualite aussi.J'attend une version + stable.

 
Lorsque j'ai utilisé la version XMPEG 4.2a de Flask, j'ai été surpris de ne pas avoir de problème de plantage. Manifestement, les corrections de bugs ont été bien faites. Dans son comparatif des encodeurs avi qur MPEG4-fr, slyde conclut ainsi :

 
 
Je vous conseille d'aller voir ce test très bien fait ici :
http://www.mpeg4-fr.com/index2.php?page=comparoenc