Guillaume POIRIER a écrit 243 commentaires

Le Cell, désolé si je vais choquer certains, mais d'un point de vue architecture, c'est une bouze infâme.
Les concepteurs du Cell ont cherché à maximaliser le rapport puissance de calcul/transistors, en laissant de côté la programmabilité.
Ils auraient mieux fait de prendre la direction des multi-coeurs homogènes comme le Xenon de la Xbox360.

Donc non, je ne suis pas intéressé par écrire des optimisations pour le Cell, sachant que:
- je n'en profiterais même pas
- elles sont susceptibles d'être caduques à la prochaine génération du Cell
- je programme pour des vraies machines, pas des jouets :o)

C'est surtout le décodage des vidéos H.264 qui a été optimisé, car c'est ce qui en avait le plus besoin (dans le sens où la plupart des G4, si ce n'est pas tous, décodent déjà parfaitement le MPEG4-ASP (XviD)).
Il y a eu aussi des décodeurs pour format de vidéo moins populaires qui ont été optimisé, mais je sais plus lesquels.

En tous cas, si tu peux faire un rapide test de performance de décodage H.264, entre RC1 et RC2, je suis curieux de voir les chiffres.
Sers-toi de la commande:
mplayer -vo null -nosound -benchmark ma_video.mp4

J'arrive pas à croire que ce genre de réflexion ait été marqué comme pertinente par les lecteurs de linuxfr.

Autant tu as raison qu'une partie du code C qui ne compilait pas avec GCC-4.x était moche, et le fait de l'adapter pour qu'il soit compatible avec GCC4 a été une bonne chose, autant les modifications qu'il y a eu à faire pour adapter l'assembleur inline a été un vrai cauchemar. La faute à certaines version de GCC qui ne respectent même pas les spécifs de leur propre docs. La faute aussi à l'équipe de GCC qui considère que c'est normal qu'un code ne puisse compiler que quand on active les optimisations: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11203#c14 , la faute à l'équipe de GCC de considérer que c'est une situation normale que GCC ne puise pas réaliser son allocation de registre avec certains codes asm inline valides.
Oui, le code de MPlayer n'est pas ce qu'on puisse rêver de mieux en matière de qualité de code, mais ton aide est la bienvenue si tu veux remédier à ce problème.

Exemple : aujourd'hui est sortie une nouvelle version du XviD avec un support du SMP. Or, pas d'options (du moins pas encore) dans Mencoder pour configurer le nombre de threads à utiliser.

Vos désirs sont des ordres! :-) : http://www1.mplayerhq.hu/cgi-bin/cvsweb.cgi/main/DOCS/man/en(...)

Je dois dire que pour MPEG1 et 2, je n'en sais rien mais je ne serais guère étonné que ces deux normes étaient déjà à débit variable.
Par contre, les normes VCD, XVCD et DVD placent des contraintes assez chiantes pour garantir un bon décodage par les platines hardware. Ils ne requièrent pas de débit constant si je me rappelle bien mais par contre, ne permettent pas une grosse variation du débit (sans doute une question de tampons de données).

Est-ce que quelqu'un sait si Xvid64bit / linux64bit/amd64 est réellement plus rapide que Xvid32bit/linux32bit/amd64 ??

Quand les optimisations ont été portées, j'ai fait un bench: http://list.xvid.org/pipermail/xvid-devel/2005-January/00481(...)
Par exemple, sur ma machine je suis passé de 44fps à 51fps en 64 bits. C'est ridicule du tout, non?

Autrement dit, est-ce que le mode 64bit permet un gain en performance pour les application desktop/multimedia?

Les différences de perfs en 64 bits sont surtout sensibles sur des bouts de codes de calcul intensif, et où on manipule suffisamment de données pour bénéfi
cier des 8 registres suplémentaire.
En général, les applis sur AMD64 sont plus rapides, à quelques exceptions près.

D'autre part, est-ce que FFMpeg est compatible 64bit?

Oui, depuis 1 an et demi ^_^! (cf le même lien pour avoir une idée des perfs).

Le but est de savoir si ca vaut la peine d'installer Debian Etch 64bit, ou s'il vaut mieux rester en 32bit? Attention : je veux pas m'embeter avec un mélange 64bit et 32bit chrooté!

Ma machine est tourne exclusivement en 32bits depuis un an. L'unique raison pour laquelle je garde un chroot 32bits c'est pour pouvoir lire de vidéos WMV3
et quelques codecs pervers de ce genre (puisqu'on passe par les codecs binaires de MS).

Toutes les autres applis digne de ce nom sont portées depuis fort longtemps.

Tout encodage vidéo est [presque] par définition à débit variable.
Plus précisément, le codec utilise un tampon qui se rempli/vide en fonction de la complexité de la vidéo à traiter. Je ne sais pas de tête quelle est la durée du tampon, mais c'est de l'ordre de quelques secondes. Ça veut dire que sur la première passe de vidéo, ton débit vidéo va être respecté à chaque fois sur un intervalle de temps définit.

Le mieux, c'est de faire un encodage en 2 passes: la première regarde la complexité de la source, et la deuxième utilise ces stats pour décider comment adapter le débit vidéo sur l'ensemble de l'encodage.

Concrètement, ça veux dire que tu fais une première passe avec:
pass=1:bitrate=xx
et une 2e passe avec
pass=2:bitrate=xx

Pour ce qui est de la sélection de bitrate automatique, ça ne marche pas exactement comme tu le voudrais. Le plus simple pour toi et d'encoder à quantizer constant, fixed_quant=2 ou fixed_quant=3
Tu peux baisser encore le quantizer si tu veux faire baisser la qualité de ta vidéo.

Pour ce qui est de l'option cartoon, il ne faut pas attendre des miracles: c'est juste une heuristique qui est sencé mieux marcher, mais si tu encodes à faible débit, ça ne peut pas faire de miracles.

C'est certes actuellement une plateforme alternative majeure, mais qui est en voie de devenir encore plus confidentielle maintenant qu'Apple a décidé de ne plus utilser de PPC dans ses machines à venir.

C'est d'ailleurs vraiment dommage, parcequ'au niveau design, le PPC c'est bon, mangez-en (alors que l'x86 est une vrai pub anti-drogues: ne fumez pas de crack quand vous concevez un processeur pour les 20-30 années à venir! :) )

Les problèmes de corruption de disque ne sont toujours pas réglés. MPlayerHQ est à nouveau dans les choux.Utilisez les miroirs: http://www4.mplayerhq.hu/homepage/design7/news.html(...)

Dans la catégorie " Related Projects" , tu as une section "Windows" où j'espère que tu trouvera ton bonheur. http://mplayerhq.hu/homepage/design7/projects.html(...)

La GUI, telle qu'elle est, fait chier pas mal de monde, et ça fait un moment qu'il est question d'implémenter toutes mes fonctions utilisées par la GUI en "slave mode", de façon à pouvoir éjecter la GUI existante, qui n'est que peu maintenue, et n'a pas été écrite de façon assez propre pour fonctionner dans une environnement non-Unix.

Les projets de GUI autour de MPlayer sont bien plus sympas que la GUI d'origine.

:-)

Merci à Google de faire un effort pour populariser Jabber, parce que quand on voit comment la fondation Jabber s'en tire...
Je pense qu'il ne faut tout de même pas être trop naïf: Google utilise des technos libres d'une part parceque c'est pas cher, d'autre part parcequ'il y a vraiment de très bon produits sur lequels il est possible d'ajouter une valeur ajoutée que la communauté n'a pas forcément les moyen de s'offrir.
Chez Google, ce ne sont pas des phylantropes, mais par contre, il est certain qu'ils ont compris qu'il ne gagneraient rien à adopter l'attitude de M$.

Il n'empêche que malgré ma méfiance quand aux outils qu'invente Google pour les raisons sus-nommées, il est clair qu'ils sont franchement géniaux et sympas.

Merci à tous. La collecte est à présent terminée depuis quelques jours déjà. La liste des donateurs se trouve ici: http://mplayerhq.hu/homepage/design7/donations.html(...)

Le nouveau serveur ne sera pas disponible en production avant environ 3 semaines.

Je posterais un journal lorsque je disposerais des photos du serveur.

Encore merci! :-)

J'ai viré GCC-3.3 (vengence personnelle puisqu'il produisait du code incorrect à partir d'assembleur inline), et j'ai gardé GCC-3.4 (avec lequel je compile tous mes programmes C) et GCC4 (puisque de toutes façons on peut pas faire autrement).
A part pour du CPP et des tests de compatibilité de ton code (raison pour laquelle j'ai aussi GCC-2.95), GCC4 n'a pas d'intéret autre que l'inauguration d'une nouvelle branche de GCC à l'avenir prometteur.

J'ai mis en ligne mes coordonnées bancaires. Il y a celles d'autres gens de la CE: http://www4.mplayerhq.hu/homepage/design7/news.html(...)

Oui, c'est vrai que les 1U sont plus cher. Mais ce sont des machines qui sont plus adaptées pour un hébergement en salle machine de FAI, et de plus elles ont généralement des dispositifs redondants comme une double alim et autres joyeusetées qui devraient éviter bien des désagréments.

Le compteur devrait être rajouté dans les jours qui viennent. Pour le moment, la somme d'argent récoltée s'élève à 700 euros.
Il faudrait environ 1700 euros pour un serveur seul. Pour l'hébergement, c'est une autre histoire. MPlayerhq consomme vraiment beaucoup de bande passante pour redistribuer les codecs binaires et les bouts de vidéo. Je dois dire que je n'ai pas une idée claire de ce que ça coûte, mais l'idée, c'est qu'une âme charitable l'offre gratuitement.
Si jamais il y avait de l'argent exédentaire, il est question d'aider certains développeurs clef. Par exemple, Michael Niedermayer, le mainteneur de FFmpeg, auteur du codec Snow et autres sorcelleries aurait besoin d'un ordi portable décent.

Le serveur actuel a attend un load de 800 (nombre de processus dans l'étant "running" en attente d'être exécutés), et ça continue de grimper, du coup la site principal de MPlayer est injoignable (utilisez les miroirs comme http://www4.mplayerhq.hu/homepage/design7/news.html(...) )
L'air conditionné montre à nouveau des signes de faiblesse.

La machine va probablement devoir être arrêtée pour préserver les données, qui ne peuvent pas être copiées ailleurs faute de place (120Go).

C'est chiant la technique quand ça lâche de tous les côtés...

L'annonce officielle est à présent online: http://mplayerhq.hu/homepage/design7/news.html(...)

J'oubliait: Les offres de dons peuvent être envoyées sur la ML: mplayer-dev-eng AT mplayerhq.hu (http://mplayerhq.hu/mailman/listinfo/mplayer-dev-eng(...) pour pouvoir poster) ou si vous avez des questions ou si vous ne souhaitez pas vous inscrire vous pouvez me joindre par mail: poirierg AT gmail point com

S'agit-il d'un appel aux dons (matériel ou financier) ?
Oui, en effet, il s'agit d'un appel au dons (matériels de préférence) assez urgent. Tant que le problème ne sera pas règlé, on risque de voir les branches de chaque développeur diverger, ce qui risque d'être coton pour re-synchroniser tout ça.

D'où vient l'annonce ?
http://mplayerhq.hu/~alex/homepage/design7/news.html(...) (la page de mainteneur de MPlayer)
Ça devrait être sur la page principale, mais comme elle est aussi dans le CVS, on ne peut pas la mettre à jour pour le moment.
Bref, on est dans la merde!

Est-il possible de virer les autres versions de GCC installer 3.x, 2.xx s'il y en a encore ?

La transition à GCC4 a été un peu la laborieuse dans certains projets, comme par example MPlayer, dont l'un des fix cassait le code généré par GCC-3.3 (la faute à GCC-3.3 puisque GCC-3.4 ne pose pas de problème).
Mais bon, ça y est, depuis moins de 24h, on peut compiler partout MPlayer avec GCC-4.0 : http://www1.mplayerhq.hu/cgi-bin/cvsweb.cgi/main/postproc/swscale_t(...)
\o/

Bon, sinon, si vous avez du temps pendant l'été, la traduction française de la doc de MPlayer aurait besoin de bonnes âmes! :)

Stéphane, j'ai commencé la traduction, à toi de jouer! :-)
J'ai copié/collé la version anglaise, que je te propose de modifier sur place, en commençant si possible à l'endroit où le dernier traducteur s'est arrêté.
Bon courrage!

Ah, ça, c'est gentil... Merci!

Où en est-tu dans tes essais d'ailleurs? Tu as essayé mencgen?

... existe aussi dans x264 d'ailleurs!

Puisqu'on y est, pourquoi pas en profiter pour dire que le support de la quantification adaptive (encore appelée "luminance masking") a été ajouté hier?
À présent, il me semble que tout ce que le frontal d'XviD gère, MEncoder le gère aussi. Si c'est pas le cas, vous pouvez m'en faire part, je m'en chargerais.