Lecteur XVID - Page 1

Est ce viable, avec du vorbis en guise de son ?

Le peu que j'ai reussi a compiler semble quand meme assez lent, mais je pense (en fait j' ai aucune preuves) qu' atteindre du 15 fps est possible (avec de l'asm biensur) par contre, gerer le vorbis en plus sera deja plus difficile.
Parmis les 3 fonctions de l' API xvid, j' en ai 2 qui marchent (du moins qui semblent marcher) et la 3, celle qui decode et biensur la plus balaise, foire. Apparemment je dois avoir un pb de compilation (genre pb de configure) parceque le code est tellement bien fait qu' il ne faut que tres tres peux de retouches (en fait, juste remplacer les fonctions d'allocation de memoire par celle de la gp). J' ai regarde les makefile et configure, mais j' ai pas capte grand chose. Vu que j'ai pas de gp, je test sous geepee, peut etre que c'est lui qui bug mais c vraiment tres peu probable...
Avis aux amateurs de playeurs ultra motive qui serait pres a ce joindre au projet ...(ca sert a rien de faire la taupe)

Precision sur l' API xvid :

elle est composee de 3 fonctions

1- initialisation (allocation memoire, declaration des variables....)
2- creation d' une instance de decompression
3- decompression a propremement parle d'une image

En gros apres execution de 1 et 2, il faut fournir a 3 un flot de donnee xvid (format mpeg4). Ceci implique, si on utilise le format de fichier AVI, d'extraire le flot (bitstream) de chaque image contenue dans l' AVI, et de presenter chaque flot (bitstream) a la fonction 3.
L'avantage de cette api est qu' elle peut decompresser une image vers le format RGB555 (qui a priori est le format 16 bits de la gp).

Pour l'instant, j'arrive a extraire une image d'un avi, mais la decompression bug.
La compilation en static fonctionne.

Bonne chance a toi

Ce serait génial en tous cas de pouvoir lire ce fabuleux format sur GP !
même si le son est en mp3 ça peut suffire...
Quand on voit que movie park tourne à 66Mhz il doit être possible en optimisant à mort de faire du 15fps et peut être même du 20fps sur GP32 avec un overclock à 133Mhz.

En fait ce qui serait cool ce serait un player de mpeg1 car le format est simple à décoder et le processeur de la GP32 peut encaisser le 25fps. Seul problème : le rapport taille de fichier/qualité est très inférieur à ce qu'on trouve avec le mpeg4.

Ce serait génial aussi d'avoir un bon player de Ogg pour remplacer le player de mp3 officiel... (avec un EQ !)
Enfin.... on peut rêver ;-)

y deja un player Ogg en cours de dèv....y avait une béta y a pas longtemps....


Si tu veux un coup de main Demi-Lait, je suis la, je ne sais pas si je pourrai vraiement t'aider, mais je propose toujours....au moins pour des test on GP.

Je soupsonne fortement une incompatibilite de version xvid. J' ai une video test encoder en xvid du 04/2003 alors que l' api que jutilise (0.9.1) date du 02/2003....hehe j'espere que c ca, pasque sinon la je sais plus

Super : avec 0.5 fps ca va etre la joie

LOL ! c'est déjà génial d'avoir réussi à afficher qlqchose !
Maintenant il faut être un génie de l'optimisation pour faire du 15fps !

Quelqu'un pourrait il me dire si geepee32 c du real time ou bien ca depend du proco du PC ou bien si c plus lent que sur hard ?

c'est lent et je pense pas ke ça dépende de ton proc du pc (ou si peu)

c'est vrai que c'est lent. Quand on voit la différence de framerate entre la version GeePee32 des émulateurs et sur la vraie machine ça fait mal (cf: screenshots des émulateurs de Rlyeh). Parfois ça va plus de 10x plus vite sur GP32.

héhé bonne nouvelle alors, faut faire des tests hardware....

yes rassure toi sur GP c bien plus rapide qu'avec l'emu ( mais desfois un prog passe tres bien sur l'emu et plante sur la vrai becane )
donc faut testé
bravo pour ton travail

config minimum pour faire tourner GeePee :

- Pentium 7 à 15 Ghz ou Athlon 2² +++ 13000
- 22 Go de Super-DDR Ram
- un écran 4 pouces
- windows 98

moi j'ai mieux!
133 Mhz et 8 Mo ram
16 Mo sur disquette (meme pas besoin de disque dur)
résolution 320x240
alimentation avec 2 piles AA
et voilà GeePee32 tourne à 100% avec vitesse et son et en plus il est portable!

Pourtant c bizarre quand on lance geepee, ya le logo de gamepark ki apparait, et la boule qui rebondit. La premier fois que jai vu ca je me suis dit que la vitesse etait vraiment elevee. Alors je me suis dit que c t pas du real time...mais bon puisque vous le dite tant mieux

le début est presque en pleine vitesse.....mais ca ralenti vite !!

Par contre Demi-Lait, vu que tu a bidouiller lma dedans, c'est dure de faire un lecteur Ogg Vorbis ? Tu as des sources de player de portebles ? Parce que moi ca me botterais bien un peux.....

ben pour les source ya le site officiel

lecteur video = decompression du flux vorbis a l'aide de la lib ogg-vorbis puis envoie a la fonction pcm de la gp

lecteur video=decomp audio+video+synchro+.... donc un peu plus complique quand meme

Ensuite tout depend du degre de complexite que l'on s'impose (fonctions du lecteur par ex)

Bon alors a premiere vu, en comptant avec un chrono ca fait un peu plus de 1 fps sur le hard non overclocker....donc ya de l'espoir

Quelle est la différence entre le format divx et xvid?

tes calculs tu les faits en virgule fixe ou en flottant ?
parce que ca ca change tout!

du 16.16 c pas mal et ca assure bien pour un proco arm qui veut de l'alignement
32bits

Jason pour repondre a ta question :
Apres avoir sortie le codec 4.12, certain membres de la team DivX voulait faire payer le codec, d'autre non.
Les autres ont former le XivD basé sur les sources du DivX et ils ne le font pas payer et il l'ontmis en Open Source.

Apres question encodage, certain te dirons que le XivD est mieux, d'autres non, perso je prefere le XivD, généralement tu as une meilleur qualité avec la meme taille a la fin.

yoyofr : c du fixe, mais bon je me suis pas plongé a fond dans le source. Actuellement je compile avec gcc, et le source c'est du pur C (enfait jai rien ecrit, juste adapte pour compiler la lib xvid). Avec du passage en ASM ca devrait booster, et pour ca faut que je traduise de l'ASM mmx en ARM (vu que le asm mmx est deja ecrit)

et il est compatible divx, vu que j'encode en xvid pour le moviepark....

Bon courage DeMI-LAIT, ce qui pourrait être pas mal, ce serait de faire un player de XVid qui puisse ne jamais avoir de désynchronisation image/son (contrairement à movie park) quitte à sauter qlqs images à certains moments.
Normalement le codec Xvid peut lire le Divx 5.

plus precisemment, ca fait du :
- 1 à 1.5 fps en 66MHz
- un bon 2.5 en 132 MHz

Question :
J'ai un pote qui m'a dit que ca ne servait pratiquement à rien de coder en assembleur, vu que gcc est très optimisé pour l'ARM.
Au départ je voulais coder en ASM les parties de la lib coder en asm mmx. Si elles sont coder en asm, c'est que ces parties doivent être les plus rapides car très utilisées pendant l'execution (logique) . Mais quand mon amis me dit ça, je suis dans le doute...
Néanmoins, Zardos Jones, au départ, est parti de 2-3 fps (en 132MHz je crois), et a optimiser le tout jusqu'à 25 fps... Est ce que quelqu'un sait s'il est parti d'une lib, ou de rien, si son code optimisé était du pur C ou bien contenait beaucoup d'assembleur ?
Actuellement le code que j'ai c'est du pur C, pensez-vous que des partis en ASM apporterait de la vitesse ? (si on suppose que c'est correctement coder)

mici

Bon alors ce que je crois :

Le moviepark il tourne à 66MHz en 10 fps avec son.
La j'ai du 2.5 fps en 132 MHz.

Les différence entre xvid (divx5) et divx4.12 existent mais ne sont pas faramineuses à ce point, et l'écart de puissance n'est pas si important.

Donc il doit certainement être possible d'optimiser le tout et d'obtenir un résultat plus que potable, en passant par l'ASM.
Je pars du principe que les gars de la Xvid team, on un bon niveau en C, et donc, je ne vais pas chercher à optimiser le C (peut-être que je me trompe...), d'ailleurs j'ai quand même pas mal regarder et n'ai rien à dire sur leur façon de coder....

Logiquement il devrait y avoir un nouveau moviepark d'ici peu, on pourra voir à quelle vitesse il tourne et combien de fps il peut se manger...
J'ai une question bête mais... le Ogg ça pompe bcp plus que le MP3 à décoder ?