Hé oui, PX3 annonce encore que c sa dernière version mais bon...
 
Alors quoi de 9 depuis la 0.0.7 (je reprend de là car la 0.0.8 est passé tellement rapidement que persone n'as eu le temps de gérer !).
 
PX3 as remis le code -r1 qui ne bugge pas (mais qui est un peu plus lent). donc fini le fameux bug du -r1
 
Et il s'est pas géné pour ajouter d'autres IDCT ! Voici donc la nouvelle liste :
-r0 (64-bit floating-point iDCT)*
-r1 (32-bit MMX iDCT)*
-r2 (16-bit MMX Chen iDCT)
-r3 (16-bit MMX AAN iDCT)
-r4 (3D-Now capable CPU (K6/Athlon))*
-r5 (SSE capable CPU)*
-r6 (FAST IDCT (IEEE ASSP-32 compliant) by Miha Peterel)*
-r7 (64-bit FPU IDCT (IEEE-1180 reference compliant) by Miha Peterel)*
 
(* : IEEE compliant)
 
Alors ceux qui connaissent flask ne seront pas déçus, les iDCT ajoutés viennent de là . Le SSE est donc l'équivalent au code de Flask-Intel, le 3D-Now celui de Flask-AMD et les deux iDCT de Miha égalements bien connus
Nottez que quasiment tous ces iDCT étaient déjà compilés dans la dernière version de Flask de PX3.
 
Alors, voici donc mon petit test.
J'ai toujours un PIII-550@617
 
Petit détail, si vous voulez tester mpeg2avi, ne vous fiez pas au temps final annoncé, il y as un bug et il affiche une minute de plus. Retirez donc une minute pour avoir la vraie durée.
 
Vidéo : premiers 50 Mo du film Stigmata. Pal, zone 2. 1306 frames.
 
Encodage : DivX Low motion 910 Kbps.
 
ligne de commande :
 
mpeg2avipx3 -b test.vob -f2 -a -rX -o8 e:
 
-r0 (64-bit floating-point iDCT) :
Temps de calcul : 9:03 minutes
fps : 2.40
 
-r1 (32-bit MMX iDCT) :
Temps de calcul : 2:06 minutes
fps : 10.34
 
-r2 (16-bit MMX Chen iDCT) :
Temps de calcul : 2:02 minutes
fps : 10.71
 
-r5 (SSE capable CPU) :
Temps de calcul : 2:12 minutes
fps : 9.84
 
-r6 (FAST IDCT (IEEE ASSP-32 compliant) by Miha Peterel) :
Temps de calcul : 2:09 minutes
fps : 10.06
 
-r7 (64-bit FPU IDCT (IEEE-1180 reference compliant) by Miha Peterel) :
Temps de calcul : 3:02 minutes
fps : 7.15
 
Même clip mais en 512*224 :
 
ligne de commande :
 
mpeg2avipx3 -b test.vob -f2 -rX -a -1 512 224 -3Y 296 -o8 e:
 
-r0 (64-bit floating-point iDCT) :
Temps de calcul : 7:59 minutes
fps : 2.72
 
-r1 (32-bit MMX iDCT) :
Temps de calcul : 1:22 minutes
fps : 15.80
 
-r2 (16-bit MMX Chen iDCT) :
Temps de calcul : 1:16 minutes
fps : 16.99
 
-r5 (SSE capable CPU) :
Temps de calcul : 1:26 minutes
fps : 15.07
 
-r6 (FAST IDCT (IEEE ASSP-32 compliant) by Miha Peterel) :
Temps de calcul : 1:25 minutes
fps : 15.33
 
-r7 (64-bit FPU IDCT (IEEE-1180 reference compliant) by Miha Peterel) :
Temps de calcul : 2:22 minutes
fps : 9.14
 
 
Alors, je n'ai pas fait de test -r3 car il est impossible de sortir en fichier ce iDCT, il ne sert que pour les preview.
Je n'ai pas non plus testé le -r4 puisque j'ai un Intel (donc sans 3DNow !). Je referais ces tests sur le Thunder bird 900 de ma soeur dès que possible (ce we normallement).
 
Mes conclusions :
 
Alors sans grande surprise le -r2 arrive toujours en tête niveau vitesse. Mais il n'est pas non plus IEEE compliant (même si franchement je vois pas de différences ).
Chose assez étonnante, la vitesse du code SSE, qui est équivalent en qualité au -r0, il faut tout de même le rappeler ! Si vous voulez absolument de la qualité maxi, c le meilleur choix ! (sur Intel). Sur AMD je ne sais pas encore mais si les perf sont au même niveau...
 
Ensuite les algo de Miha sont aussi très bon et surtout IEEE compliant aussi. Mais légèrement plus lent que le -r1 d'origine de mpeg2avi qui est lui aussi IEEE compliant...
 
Voilà, vivement que des programmeurs ASM se mettent sur mpeg2avi ! Cela pourrais faire très mal. En tout cas sur un bon processeur, mpeg2avi peu être plus rapide que le film pour encoder (plus de 25 fps), et ça, c'est quand même impressionant !
 
Allez

--Message édité par bruce--

encore me,
 
dis-moi bruce, j'ai jamais "tripoté" ses machins ds la GUI.
 
y servent à koi exactement ?
 
on les choisis en fontion koi (à part ce "special matos of course).
 
@+
 
jaja

Ben en fait l'iDCT c'est ce qui décode les frames MPEG2. dès lors plus l'algo est rapide plus rapide est l'encodage.
Mais joue alors le problème de la qualité. Les algo certifiés IEEE (IEEE compliant) ont tous une qualité théorique irréprochable.
 
Pour vous donner une idée, les filtres des softs tels que PowerDVD ou WinDVD ne sont pas IEEE compliant pour justement jouer là dessus et gagner en vitesse. Mais bon, pour matter un film ça passe très bien qd même

Pour booster le nombre de FPS, une version DOS de mpeg2avi ne serait pas si bête. On boot sur une disquette DOS 7 et on lancerait mpeg2avi. Simplement. Il aurait 100% du CPU à lui tout seul !!! Exit Windows et compagnie
Malheureusement, tant que DivX n'est pas en version DOS....

C'est surtout impossible à faire !
 
Les codecs sont tous enregistrés sous windows, la mémoire est pas gérée pareil... Bref, mpeg2avi c un prog dos sous win

wxcvbn a écrit a écrit : Pour booster le nombre de FPS, une version DOS de mpeg2avi ne serait pas si bête. On boot sur une disquette DOS 7 et on lancerait mpeg2avi. Simplement. Il aurait 100% du CPU à lui tout seul !!! Exit Windows et compagnie Malheureusement, tant que DivX n'est pas en version DOS....

 
Ca a existe DOS 7 ? j'ete reste aux version 6.22 ou quelque chose comme ca...
De toute facon que gagnerais tu : la limitation de la FAT16 ? la limitation des 640 ko ? Non crois moi c'est un mythe que de croire que le DOS est plus rapide que Win. tu gagne quand meme a avoir un systeme 32 bits (enfin presque)...

Je voulais savoir, avec toutes ces nouvelles options qu elle est celle qui donne un film de meilleur qualite ?
toujours -r1 ???
A+

Comme je l'ai déjà dit, toutes les options qui sont IEEE compliant sont de même qualité (la meilleure ).
 
Sinon, oui le DOS 7 existe c'est celui qui était déjà dans Win95, c'est lévolution du 6.22...
 
Le DOS 7 est, comme Windows, FAT 32 et autres (d'ailleur, fdisk que tu lance à partir d'une disquette de boot te le prouve.)

--Message édité par Bruce--

Puisque le -r5 c'est du -r0 optimizé SSE et que ca va aussi vite que le -r1, autant s'en servir pour ceux qui ont de P3 ou des celerons 2...

Il est un chouilla plus lent qd même...

Les 640 Ko ça se casse. Souviens-toi DOOM l'été dernier ... avec son bon vieux gestionnaire de mémoire protégée "DOS4/GW Extender". Mais bon, je ne fais pas une fixation sur DOS. Je pense simplement que windows n'est pas l'OS idéal pour lancer un traitement aussi lourd. ça bouffe de la ressource inutilement cette bête là . De plus si on laisse l'anti-virus, et tous les programmes qui sont gentillement affichés en bas à droite de l'écran. C'est la cata !

--Message édité par wxcvbn--

 
 
Un micro-mini-chouilla ss
chez moi ca se tient à 0.1 0.2 fps
 
au fait, personne n'a un P4 pour voir?

Autant ne pas se priver en effet
 
Pour windows, c clair mais pour le moment on n'as pas mieux pour le DivX...

heu ,je peut avoir un lien pour le D/L

Ben comme tj : px3.does.it.
 
Et si vous voulez avoir tous les softs en rapport avec le DivX je ne peu que conseiller l'excellent doom9 : www.doom9.net ou go.to/doom9.

Comment on intège la version 009 dans la Gui du Rippack ?

Euh mais si on le portait sous BeOS ou Linux ??
 
 
 Ce serait mieux non ????ss:confused:

moi j'ai eu le temps d'intégrer la 0.0.8 dans ma 3.5b !
 
ha ha ha
 
nan sérieusement merci bruce, mais y'a pas le SSE2 là ?

Pour mettre la 0.0.9 sur la GUI il suffit de mettre mpeg2avipx3.exe ^à la place de celui du rippack (dans le répertoire logiciels/mpeg2avi). Ou alors changer la configuration de mpeg2avi si vous le décompressez ailleur
 
Sinon, pour intégrer les autres modes (-r5 et plus) je vais le faire... G pas encore eu le temps. Modifiez le .bat si vous voulez les utiliser pour le moment.
 
Jesus, non j'ai rien vus pour le moment mais comme g pas de PIV...

personne n'a de p4, mais ça fait joli, stype programme super récent, surtout que moi avec mon interface DOS j'en aurais bien besoin D
 
A+

Euh bruce, matte un peu les sources, y a plein d'asm la dedans...
 
Sinon jvé me mettre au -r6 moi, très bon compromis

Dans le fichier zip de la version 009 y'a plein d'autres fichiers, ils servent à rien ??
Quand je sélectionne le nouveau .exe il ne met pas les autres IDCT en plus mais toujours les 5 de l'ancienne version. Help

les autres fichiers c le code source..
 
Tu fais comment pour choisir ton iDCT?? chez moi ca marche bien..
si tu le fais avec le rippack tu doit éditer le .bat

Si bruce ne met pas à jour son interface Rippack, ça m'étonnerais qu'il t'affiche les nouveaux choix d'IDCT
Tiburs1.

Juste une petit Questiojn fait 'il toujour autant d'erreur (bad frame)

m'a jamais fait une bad frame M2A... verifie ton systeme s'il est overclocké

pas overclocke le systeme il fonctionne bien meme et je crois que je ne suis pas le seule avoir des bad frame. C'est meme assez courant

bad frame? c quoi?
 
j'en ai jamais eu..

Donc je peux pas m'en servir de cette nouvelle version !! ss:sweat:

si, tu peux !
tu crées un .bat et tu l'édites.
pas compliqué qd même

Comme le rippackgui.bat qu'il créé en fichier temporaire sauf que je remplace -r2 (par exemple) par -r5 (par exemple).C'est ça?

ouiiiiiiii

Ca y est j'ai réussiss:sol: J'suis vraiment une bêtess
 ss
Quelle différence y a-til entre le 32bit et le 64bit ?
C'est quoi 64bit FPU IDCT (IEEE-1180)sset FAST IDCT IEEE ASSP-32 ?
Pour avoir la meilleure qualité d'image lequel dois-je prendre ? (peut importe le temps d'encodage)
 
PS :J'ai un Duron 700@920

Hé, dit donc il serait temps de lire ce que les autres écrivent très cher Moa_ !
 
"Les algo certifiés IEEE (IEEE compliant) ont tous une qualité théorique irréprochable."
 
Prend donc l'algo IEEE le plus rapide chez toi...

Pour la vitesse d'encodage je confirme ce que dit bruce,
sur VP6 bi-P3700@980 Mhz avec taux d'occupation CPU a 65% je fais:
 
24-25 fps en -r5
29-30 fps en -r2 (tjs le plus rapide)

Dis-moi tu as C perfs avec un seul des cpu ??

Oui je confirme, mpeg2avi charge un bi-CPU à 65% (j'ai un bi-p2), pas 50% alors que c'est sencé être un truc mono CPU.
 
Donc on a 30% de perfs en + avec 2 CPU

temps réel voir + en encodage avi !!!
 
oula, je vais me racheter un bi-cpu moi !!

oui je fait du 65% sur les DEUX cpus (SMP=symetric multi procs !) et effectivement c'est bizarre de faire plus de 50 % de charge CPU mais en fait vu que mpeg2avi balance plusieurs treads "ca compte" comme plusieurs applis memme s'il est pas optimiser bi-proc ... moi j'aimerais bien qu'une version bi-proc sorte et bouffe mes deux cpu a 100 % (ca ferait quoi, 40-45 fps ... ahhh!!)

Héhé, c cool ça ! Vivement mon CPU à 1 Go !