Pour la doc à traduire, le plus simple c'est de la commencer sur une page de wiki. Comme ça je pourrai m'y mettre un peu à temps perdu.
Ok, si tu as un wiki à toi... Sache seulement qu'il existe déjà une grosse partie de la doc html qui est traduite. Par contre, la partie x264 est assez nouvelle et ne l'a pas encore été.
J'espère avoir de tes nouvelles bientôt. Utilise la redirection dlfp ou les messages privés.
Bon ben je vais fouiller le forum doom9 dans les semaines à venir et déposer ce que j'y trouve ici.
Bonne idée.
Pour xvid, voici ce que j'utilise:
lumi_mask:me_quality=6:chroma_me:chroma_opt:trellis:closed_gop:max_bframes=2:hq_ac:vhq=4:bvhq=1:autoaspect:psnr:qpel:min_iquant=1:quant_type=mpeg:quant_intra_matrix=/mnt/fatty/G/ShartIntra.matrix:quant_inter_matrix=/mnt/fatty/G/ShartInter.matrix
Te fatigues pas trop à comprendre, ça consiste grosso-modo à tout activer les options d'encodage :-).
La toute dernière partie fait intervenir un matrice de quantisation personnalisée que j'ai touvé sur le forum doom9. C'est la matrice ultra low bitrate de "Shartooth".
Pour l'encodage bas débis, je te conseillerais d'une part d'utiliser la version CVS d'XviD qui corrige quelques bugs de la version beta2, qui elle-même améliore le support de l'encodage bas débit. J'ai essayé de jouer un peut avec l'encodage à 200kbps d'une vidéo 704x304 et je dois avouer que le résultat n'est pas dégueux pour un débis aussi bas.
Pour ce qui est des explications dans la page de man, tu avoueras que vu sa taille (elle est encore plus grosse que celle de GCC), c'est presque un miracle que TOUTES les options de MPlayer soient documentées. Ce miracle a un nom: Diego Biurrun le mainteneur de la doc, du site, et bien d'autres choses, à qui je tire mon chapeau.
Aucune indication sur le résultat obtenu selon les combinaisons, sur la façon de régler les paramètres selon la video etc etc.
Fais le calcul, il doit y avoir une 20-30aine d'options pour XviD et x264, si tu voulais discuter de toutes les combinaisons, ça fait entre 20! et 30! combinaisons à documenter. Ok, j'exagère, mais c'est pour dire...
De plus, il faut voir que la compression vidéo MPEG se base sur le fait que l'humain n'est pas sensible à certains détails en général, que l'on peut éliminer. Le problème, c'est que chaque personne ne réagit pas de la même façon à la perte de certains détails, ou à l'apparition de certains artefacts, ce qui fait qu'il est tout à fait impossible de donner une recette clée en main sur comment encoder telle vidéo.
Fais un tour sur le forum doom9.org, et tu verras qu'il y a encore des gens qui s'interrogent sur les meilleurs options pour encoder le film le plus encodé au mode: Matrix.
Pour terminer, je t'invite à chercher une des nombreuses docs sur XviD qui existent sur le net, ça te permettra d'affiner ton choix d'options d'encodage.
Si, justement, c'est d'autant plus improbable que ses géniteurs (HP, Intel, et d'autres) ont vraiment du mal à le vendre parceque ce processeur est difficile à dompter, et stagne niveau fréquence, car trop complexe. HP continue de vendre des solution superdome http://www.hp.com/products1/servers/scalableservers/superdome/(...) à base de PA-RISC alors que l'Itanium aurait dût balayer tout ça.
Pareil pour SGI qui s'était un moment tourné vers l'Itanium, et maintenant mise sur l'Opteron.
Je n'ai pas dit que l'Itanium était mort, il se trouve juste qu'il est vraiment réservé à des utilisations particulières (le calcul intensif en étant une).
Pourrait ton se prendre a rever de PowerPC gravés super fin et poussé a des cadences dignent des x86 ou c'est carrement l'archi des PowerPC qui l'empeche?
Les deux mon colonel! :-)
En effet, une micro-architecture est conçue dès le début pour atteindre une certaine fréquence. C'est ce qui explique qu'on a eu toutes ces différentes génération de processeurs (donc on ne verra jamais un P3 à 2Ghz, d'un autre côté, il me semble que le P4 devait pouvoir atteindre les 6GHz voire davantage, et ça semble ne plus être d'actualité pour les raison que l'on connaît) qui ont chacun repoussé plus loin la fréquence de fonctionnement des CPU (s'ajoutant à cela des améliorations telles que de meilleurs prédicteurs de branchements, meilleurs stratégies de cache, prefetch, etc...).
En gros, si tu prends le PowerPC 970 (G5) et que tu le donne à fabriquer à Intel, ils ne vont rien en tirer de plus que ce qu'IBM sait déjà faire. Il ne faut d'ailleurs pas oublier qu'IBM fait de très grosses recherches dans le domaine de la physique fondamentale pour toujours améliorer ses techniques de gravures. A l'heure actuelle, Intel et IBM ont à peu de chose près des technologies de gravure équivalentes
Maintenant, si tu confiait la conception et la fabrication du G6 à Intel, Dieu seul sait ce qu'ils seraient capable de faire. Probablement quelquechose de monstrueux, étant donné que le design du PowerPC ne traîne pas les casseroles de la compatibilité avec le 8086, mais à part ça, c'est difficile de juger.
Je ne suis pas convaincu par cette idée qu'Apple se tourne vers le x86... Intel ne fait pas que des processeurs x86: il y a aussi les Itaniums, les Xscales (processeurs embarqués rudement bien à base d'IP ARM).
C'est d'ailleurs l'idée que propose Ars Technica: http://feeds.feedburner.com/arstechnica/BAaf?m=524(...)
There's a much simpler explanation available. The Apple-Intel conversations that the WSJ is reporting likely have to do with Intel's Xscale CPU, a cool little chip that is fantastic for things like appliances and portable devices. Think gadgets and set-top boxes. If Apple is looking at branching out into other consumer electronics hardware, the Xscale would be a logical choice.
Tout de suite, ça devient plus logique.... après tout, il existe bien des Pocket PC à base de processeurs ARM, alors pourquoi pas de Pocket Mac à base d'ARM aussi?
Et dire que c'est pourtant la base même. L'idéal sera un jour que toute les distributions Linux comprennent que par défaut, il faut *bloquer* tous les ports pour ne laisser ouvert que ce que l'utilisateur a sciemment décider d'ouvrir. Car après tout, un novice qui installe Linux, la première chose qu'il fait pour se documenter, c'est de se connecter à Internet pour accéder à de l'aide ou de la documentation.
Permet-moi de ne pas partager ton point de vue.
Ton débutant sous Linux, il ne sait pas par quel bout prendre la plupart des problèmes auxquel il doit faire face, et veut avant toute chose avoir un truc qui marche. Rien que la connection à internet, que tu mets en avant pour accéder à la documentation, c'est un truc qui peut rapidement devenir un cauchemard (par exemple, s'il est coincé avec un winmodem, etc...
Je n'aime pas dire ça, mais je trouve que ton commentaire est élitiste et inutile.
tu ne peux pas demander à un débutant d'avoir les connaissances d'un administrateur réseau, cible de choix d'OpenBSD.
Je ne suis pas en train de prétendre qu'on ne peut pas utiliser OpenBSD comme machine de bureau, mais plutôt que tout comme c'est inutile de conduire un 4x4 en centre ville, c'est déraisonnable de mettre un débutant complet devant OpenBSD sous prétexte que c'est super sécurisé.
Tu remarquera d'ailleurs que des distributions Linux existent déjà avec la philosophie OpenBSD, et que la plupart disposent d'une installation minimale ou/et de type "serveur" limitant les programmes installés par défaut.
Pour conclure, je dirais qu'une des plus grandes contributions d'OpenBSD au libre, c'est d'avoir fait prendre conscience aux gens comme toi et moi que la sécurité se joue autant à la conception qu'au déploiement des systèmes.
Pour ceux qui ne connaisse pas Kerrighed, c'est un système d'exploitation pour grappe d'ordinateurs.
Pas du tout, efface!
C'est un patch au noyau Linux permettant de le transformer en système d'exploitation distribué.
A ce que j'ai compris, il permet un contrôle plus fin des processus qu'OpenMosix (qui permettait juste de migrer des processus entiers d'une machine à une autre), alors qu'ici, si je n'abuse, on peut distribuer au niveau thread (attention, je ne suis pas spécialiste).
Développé dans l'équipe Paris de l'IRISA de Rennes, son but premier est de permettre le calcul sur grappe, mais il doit permettre probablement bien plus.
Par contre Apple ne respecte pas l'esprit GPL/LGPL en faisant tres peu d'effort pour intégrer leurs modifications dans le projet originel, bref un fork comme tu dis.
Sans vouloir trouver des excuses à Apple, il se trouve qu'il est généralement difficile de faire collaborer des équipes de devs qui travaillent sur leur temps libre (et n'ont pas d'obligation de résultat) et des gens qui bossent dessus à temps plein et doivent sortir du produit au bout.
J'en veux pour preuve la quantité de patchs non appliqués par manque de temps dans le projet MPlayer: les contributions extérieures ne sont pas toujours dans la droite ligne du projet, et ne plaisent pas toujours à l'équipe de dévelloppement, tels qu'elles sont implémentées.
Par exemple, le projet Unichrome, qui ajoute le support des puces graphiques VIA existe depuis pas mal de temps, et a été plusieurs fois rejetté parceque le patch touchait à beaucoup de choses à la fois, certaines de ces modifications étant par ailleurs inutiles.
Si on regarde du côté de GCC, Apple a aussi sa version de GCC qui fonctionne diablement mieux pour générer du code Altivec que le GCC "normal". Or, toutes ces modifications ne se sont pas non plus retrouvées dans le "vrai" GCC pour les même raisons exposées plus haut.
Bref, Apple ne respecte pas tellement l'idéologie, mais on ne peut pas dire non plus que ça soit évident de contenter tout le monde
La je pense qu'Apple sous-estime le besoin de coopérer sainement avec des developpeurs du libres
J'aurais été curieux de voir ce qu'aurait donné une collaboration "à la Red Hat": ie: embaucher les gens du projet pour le faire avancer suivant sa volonté.
Ca marche avec RedHat, mais c'est une entreprise d'inspiration libre depuis le début.
Apple, c'est différent, ils ont toujours été très secret sur leur façon de fonctionner... bah, peut-être qu'il faut leur laisser un peu de temps... Un virage à 180°, ça se négocie par trop vite, sinon on se casse la gueule...
le temps passé dans le kernelspace est difficilement compressible.
De plus, comme tu en as moins à charger, t'as plus rapidement la main, non ?
En effet, le kernel n'est pas forcément préemptible, ce qui fait que quand par exemple il accède au matériel pour prendre connaissance des périphériques sur lequel il tourne, il me semble que le kernel passe pas mal de son temps à attendre que le matériel réagisse.
Avec un kernel préemptible, normalement on peut gagner un peu de temps de ce côté-là.
Par contre, il faut bien voir que déplacer des traitements en espaces utilisateurs, ça donne uniquement une illusion que ça aille plus vite, puisqu'au final, les traitement devront quand même être réalisés d'une manière ou d'une autre. Si on prend Windows XP par exemple, on arrive très vite sur le bureau, mais c'est pas pour autant qu'on peut déjà commencer à travailler, puisqu'une ribambelles de programmes sont encore en train de se charger.
Hum... Ce n'est pas tout à fait ça que je lis. Je vois plutôt EarlyUserspace comme un projet visant à améliorer la modularibilité des différentes étapes de configuration du Kernel.
L'exemple qu'il donnent, devfs est assez parlant: ce mordeau de code était tout moche, souffrait de bugs que personne ne voulait corriger justement à cause de la qualité du code, et en plus, n'était pas particulièrement rapide.
Cela a été remplacé par udev, que tout le monde connait, et qui donne suffisament satisfaction pour que presque toutes les distribs l'utilisent à présent.
Un autre exemple que je vois, c'est libata (j'espère que ne ne dis par de bêtise)
Mon avis là-dessus, c'est que finalement, Tanenbam n'avait pas tellement tord... :-)
Si le but est simplement d'avoir une vidéo lisible par cinelerra, le codec lavc suffit :
mencoder -ovc lavc -oac pcm input.avi -o output.avi
Où là! C'est pas forcément une bonne idée de faire un encodage avec lavc sans rajouter quelques options demandant à l'encodeur d'optimiser un peu plus pour la qualité.
Voir ici pour les options qui ont un grand impact sur la qualité: http://mplayerhq.hu/DOCS/HTML/en/menc-feat-dvd-mpeg4.html#menc-feat(...)
Sinon, le reste du guide d'encodage de MEncoder devrait de donner des bonnes bases pour faires des encodages de qualité.
NB: l'équipe de traduction de MPlayer recherche des volontaires pour traduire en français les dernières mises à jour de la page citée ci-dessus
je ne sais pas ce qu'il faut mettre pour l'audio, étant donné que je n'ai aucune expérience de ces logiciels et des caméras...
Il me semble que du pcm (c'est à dire wav) devrait fonctionner. A ma connaissance, le son n'est pas compressé dans les fichiers dv.
A part ça, si tu as encore des problèmes d'exports avec libdv, essaye de voir si tu peux pas générer un fichier 'mjpeg' (c-à-d une suite de jpeg).
MEncoder doit faire ça, sinon y'a aussi les "mjpeg tools" que j'ai utilisé et qui fonctionnent vraiment très bien.
On peut difficilement faire plus standard, et c'est il me semble le format de données qu'utilisent tous les éditeurs non linéaires de vidéo.
Ubuntu étant basé sur Gnome, je pense que l'environnemejt KDE a reçu moins d'attention.
As-tu essayé kubuntu peut-être?
Peut-être que les sources de paquets sont les mêmes de toutes façons, et que ça ne change rien, je sais pas...
Le Wikipedia, comme tout travail communautaire ne peut, je pense jamais assurer que le contenu sera toujours "intègre".
Cela dit, je pense que c'est un risque qu'on court aussi quand on utilise des logiciels libres: il faut un minimum faire confiance à ses auteurs.
Il existe, au moins au niveau des logiciels libres, quelques gardes-fous: tout le monde n'a pas un accès en écriture au CVS, ou au site web.
De la même façon, il me semble que le contenu deu wikipedia passe par une sorte de modération ou comité de relecture avant d'être disponible.
Je pense par exemple à "l'affaire Pierre Tramo" VS Wikipedia, qui a conduit, je pense, à certaines restrictions sur les articles distribués.
Cela permet, je pense de diminuer les risques, mais ça reste une question de confiance (les modérateurs peuvent toujours péter les plombs).
J'en voudrais plus souvent!
C'est clair, enjoué et complet, et ça change des sujets habituels.
Dommage qu'on ne puisse pas plusser les journaux.
Je voudrais juste ajouter un truc: il existait une autre méthode pour détecter les exoplanètes avec des télescope terrestres "normaux" (c-à-d pas des bijoux comme le VLT), c'est la détection par "éclipse":
On suit l'éclat d'une étoile, sa forme, et si son éclat change et/ou qu'on voit une forme passer devant, c'est qu'elle doit avoir une planète à graviter autour.
L'intérêt, c'est que la planête n'as pas formément besoin d'être proche, mais là encore la planète doit faire plusieurs fois la taille de jupiter pour qu'on puisse la voir.
Un autre benchmark intéressant, de Scott Robert Ladd: http://www.coyotegulch.com/reviews/linux_compilers/index.html(...)
On y apprend que GCC n'est pas ridicule lorsqu'il n'est pas utilisé sur une plateforme Intel, et qu'apparemment les binaires obtenus avec ICC sont capables de se saborder eux-même s'ils sont exécutés sur une plateforme non-intel:
Intel's compiler also produces executable code that disables some of its optimizations on non-Intel hardware. It's unrealistic to expect that Intel will create a compiler that works well on their competitor's hardware.
C'est vraiment diabolique, d'autant qu'on peut se demander ce qui se passera quand on voudra exécuter le même binaire sur les nouveaux Pentium XX, et que la détection de la plateforme échouera probablement.
Rien que pour ça, ça vaut le coup de préférer GCC! ;-)
Salut,
Moi, j'ai une Ubuntu, et tout marche nikel "out of the box". OOo, firefox (sans flash, mais c'est un plus mal), drivers Nvidia.
Je ne sais pas si certaines de ces applis sont en 64bits on non, et de toute façon, je m'en fiche, c'est pas là que les gains se trouvent.
Par contre, niveau encodage, le 18% de speed-up avec tant x264 qu'XviD que libavcodec est plus qu'agréable, d'autant que c'est gratuit.
Maintenant, je comprendrais que tu n'aies pas envie de prendre une Ubuntu si tu veux absolument un support Debian "officiel", il n'en reste pas moins que c'est la solution la plus proche de ce que tu demandes, et qui fonctionne vraiement bien.
He then successfully received a merge from arm maintainer Russell King [interview], with a comment stating, "first ever true git merge. Let's see if it actually works." The merge was a simple one as there were no file conflicts, but as a first step it helped to prove the concepts.
Les progrès se font donc à pas mesurés. Pour le moment, les fusions de branches de dévelloppement n'ont été testés que dans des cas simple, où il n'y a pas de conflit.
Là où BitKeeper excelle, il me semble, c'est en ce qui concerne la fusion plus problématique de branches entre les développeurs.
Ne nous entousasmions donc pas trop vite, le plus dure reste à venir... mais c'est clair que vu la vitesse à laquelle progresse git, je ne serais pas étonné qu'ils arrivent à relever le défit bien vite...
D'ailleurs en passant, sur la même page, on peut voir:
after a planned merge of the SCSI development branch following the upcoming release of 2.6.12, "Linux will have more advanced Fibre Channel support than any currently available operating system."
Un beau pied de nez à tous ceux qui ont décrié le nouveau mode de développement du kernel Linux.
Il permet bel et bien d'intégrer des avancées technologiques bien plus vite que par le passé.
... maintenant, qu'en est-il au niveau stabilité, j'en sais trop rien, mais chez moi, ça marche (TM).
avi demuxer: (needs rewrite)
- implement hardcore bruteforce avi re-sync for broken files (-forceidx)
- fix for growing avi files (movi_end pos > stream->end_pos)
- implement forward seeking in avi streams with no index
DOCS:
- break up 6 level deep sections
- merge tech/encoding-tips.txt into mencoder.xml
- merge iive's XvMC docs into video.xml
- finish reviewing all of the docs
- mplayer.1
- encoding.html
- video.html
- documentation.html
- enhance the FAQ
- document missing XviD options
- add Matroska, NSV and nut to formats.xml
- split man page into mplayer.1 and mencoder.1
FUTURE:
~~~~~~~
demuxer:
- demux_mpg: support for VDR's index files for more accurate seeking
- implement seeking for YUV4MPEG_2_
other:
- dvd server
- mga_vid crtc2 fix
- X11 Render support into DGA for OSD (from the DOCS;)
DOCS:
- convert man page to XML
- write a detailed encoding guide
- document missing divx4opts (everything in #if ENCORE_MAJOR_VERSION >= 5200,
vbrdebug)
Or il se trouve qu'un certain nombre de ces fonctions sont non triviales à implémenter, alors...
ca va durer longtemps ?
bah oui, ça peut, dans la mesure où beaucoups de nouvelles killer features sont proposées par des codeurs externes (qui ne font pas partie des objectifs du TODO), et que seuls les gens de la core team essayent d'atteindre les objectifs de la 1.0 puisque ça nécessite des changements plus important.
En gros, c'est le problème du Bazaar: tout le monde peut proposer son travail dans la mesure où il a de l'intérêt, mais ça fait pas forcément avancer fondamentalement le projet (vers la 1.0).
Tu me suis? :-)
je voudrais les réencoder dans un format libre pour être sur de pouvoir toujours les relire.
C'est un des grands problèmes de l'informatique AMHA: que pourra-t-on faire de nos données dans le futur?
C'est tout l'intérêt, en effet des implémentations libres.
Par contre, sur le principe, ce n'est pas une bonne idée de ré-encoder parceque tu risques de re-compresser des artefacts de compression du fichier source.
Un peu comme si tu faisais un photocopie de photocopie en somme.
Mais c'est sûr que quand on n'a pas le choix...
Quels formats audio/video libres conseilles-tu?
Certains seraient tentés de te dire Théora+Vorbis. Le problème, c'est que ce n'est pas si bien supporté que ça, et qu'il n'y a pas de grosse communauté de developpeurs derrière.
Par contre, il n'y a pas de problèmes de brevets puisque On2, la société qui détient les brevet, à juré de ne rien faire à l'encontre de Théora.
En ce qui me concerne, j'utilise plutôt XviD+Vorbis, que je connais bien, et qui est bien supporté.
[^] # Re: Bah ...
Posté par Guillaume POIRIER . En réponse au journal mencoder, xvid, x264. Évalué à 1.
Ok, si tu as un wiki à toi... Sache seulement qu'il existe déjà une grosse partie de la doc html qui est traduite. Par contre, la partie x264 est assez nouvelle et ne l'a pas encore été.
J'espère avoir de tes nouvelles bientôt. Utilise la redirection dlfp ou les messages privés.
Bon ben je vais fouiller le forum doom9 dans les semaines à venir et déposer ce que j'y trouve ici.
Bonne idée.
[^] # Re: Bah ...
Posté par Guillaume POIRIER . En réponse au journal mencoder, xvid, x264. Évalué à 1.
et en français:
http://www.mplayerhq.hu/DOCS/man/fr/mplayer.1.html#OPTIONS%20D'ENCO(...)
[^] # Re: Bah ...
Posté par Guillaume POIRIER . En réponse au journal mencoder, xvid, x264. Évalué à 7.
http://mplayerhq.hu/DOCS/HTML/en/menc-feat-x264.html(...)
(D'ailleurs en passant, si tu quelqu'un pouvait proposer son aide pour traduire ce morceau de doc, ça serait pas de refus).
Pour xvid, voici ce que j'utilise:
lumi_mask:me_quality=6:chroma_me:chroma_opt:trellis:closed_gop:max_bframes=2:hq_ac:vhq=4:bvhq=1:autoaspect:psnr:qpel:min_iquant=1:quant_type=mpeg:quant_intra_matrix=/mnt/fatty/G/ShartIntra.matrix:quant_inter_matrix=/mnt/fatty/G/ShartInter.matrix
Te fatigues pas trop à comprendre, ça consiste grosso-modo à tout activer les options d'encodage :-).
La toute dernière partie fait intervenir un matrice de quantisation personnalisée que j'ai touvé sur le forum doom9. C'est la matrice ultra low bitrate de "Shartooth".
Pour l'encodage bas débis, je te conseillerais d'une part d'utiliser la version CVS d'XviD qui corrige quelques bugs de la version beta2, qui elle-même améliore le support de l'encodage bas débit. J'ai essayé de jouer un peut avec l'encodage à 200kbps d'une vidéo 704x304 et je dois avouer que le résultat n'est pas dégueux pour un débis aussi bas.
Pour ce qui est des explications dans la page de man, tu avoueras que vu sa taille (elle est encore plus grosse que celle de GCC), c'est presque un miracle que TOUTES les options de MPlayer soient documentées. Ce miracle a un nom: Diego Biurrun le mainteneur de la doc, du site, et bien d'autres choses, à qui je tire mon chapeau.
Fais le calcul, il doit y avoir une 20-30aine d'options pour XviD et x264, si tu voulais discuter de toutes les combinaisons, ça fait entre 20! et 30! combinaisons à documenter. Ok, j'exagère, mais c'est pour dire...
De plus, il faut voir que la compression vidéo MPEG se base sur le fait que l'humain n'est pas sensible à certains détails en général, que l'on peut éliminer. Le problème, c'est que chaque personne ne réagit pas de la même façon à la perte de certains détails, ou à l'apparition de certains artefacts, ce qui fait qu'il est tout à fait impossible de donner une recette clée en main sur comment encoder telle vidéo.
Fais un tour sur le forum doom9.org, et tu verras qu'il y a encore des gens qui s'interrogent sur les meilleurs options pour encoder le film le plus encodé au mode: Matrix.
Pour terminer, je t'invite à chercher une des nombreuses docs sur XviD qui existent sur le net, ça te permettra d'affiner ton choix d'options d'encodage.
[^] # Re: Se méfier des interprétations douteuses...
Posté par Guillaume POIRIER . En réponse au journal Macos sur x86 ?. Évalué à 2.
Si, justement, c'est d'autant plus improbable que ses géniteurs (HP, Intel, et d'autres) ont vraiment du mal à le vendre parceque ce processeur est difficile à dompter, et stagne niveau fréquence, car trop complexe. HP continue de vendre des solution superdome http://www.hp.com/products1/servers/scalableservers/superdome/(...) à base de PA-RISC alors que l'Itanium aurait dût balayer tout ça.
Pareil pour SGI qui s'était un moment tourné vers l'Itanium, et maintenant mise sur l'Opteron.
Je n'ai pas dit que l'Itanium était mort, il se trouve juste qu'il est vraiment réservé à des utilisations particulières (le calcul intensif en étant une).
[^] # Re: Se méfier des interprétations douteuses...
Posté par Guillaume POIRIER . En réponse au journal Macos sur x86 ?. Évalué à 7.
Les deux mon colonel! :-)
En effet, une micro-architecture est conçue dès le début pour atteindre une certaine fréquence. C'est ce qui explique qu'on a eu toutes ces différentes génération de processeurs (donc on ne verra jamais un P3 à 2Ghz, d'un autre côté, il me semble que le P4 devait pouvoir atteindre les 6GHz voire davantage, et ça semble ne plus être d'actualité pour les raison que l'on connaît) qui ont chacun repoussé plus loin la fréquence de fonctionnement des CPU (s'ajoutant à cela des améliorations telles que de meilleurs prédicteurs de branchements, meilleurs stratégies de cache, prefetch, etc...).
En gros, si tu prends le PowerPC 970 (G5) et que tu le donne à fabriquer à Intel, ils ne vont rien en tirer de plus que ce qu'IBM sait déjà faire. Il ne faut d'ailleurs pas oublier qu'IBM fait de très grosses recherches dans le domaine de la physique fondamentale pour toujours améliorer ses techniques de gravures. A l'heure actuelle, Intel et IBM ont à peu de chose près des technologies de gravure équivalentes
Maintenant, si tu confiait la conception et la fabrication du G6 à Intel, Dieu seul sait ce qu'ils seraient capable de faire. Probablement quelquechose de monstrueux, étant donné que le design du PowerPC ne traîne pas les casseroles de la compatibilité avec le 8086, mais à part ça, c'est difficile de juger.
# Se méfier des interprétations douteuses...
Posté par Guillaume POIRIER . En réponse au journal Macos sur x86 ?. Évalué à 7.
C'est d'ailleurs l'idée que propose Ars Technica: http://feeds.feedburner.com/arstechnica/BAaf?m=524(...)
Tout de suite, ça devient plus logique.... après tout, il existe bien des Pocket PC à base de processeurs ARM, alors pourquoi pas de Pocket Mac à base d'ARM aussi?
[^] # Re: reiserfs ?
Posté par Guillaume POIRIER . En réponse à la dépêche Sortie d'OpenBSD 3.7. Évalué à 4.
C'est en route!
[^] # Re: Sortie d'OpenBSD 3.7
Posté par Guillaume POIRIER . En réponse à la dépêche Sortie d'OpenBSD 3.7. Évalué à 4.
Permet-moi de ne pas partager ton point de vue.
Ton débutant sous Linux, il ne sait pas par quel bout prendre la plupart des problèmes auxquel il doit faire face, et veut avant toute chose avoir un truc qui marche. Rien que la connection à internet, que tu mets en avant pour accéder à la documentation, c'est un truc qui peut rapidement devenir un cauchemard (par exemple, s'il est coincé avec un winmodem, etc...
Je n'aime pas dire ça, mais je trouve que ton commentaire est élitiste et inutile.
tu ne peux pas demander à un débutant d'avoir les connaissances d'un administrateur réseau, cible de choix d'OpenBSD.
Je ne suis pas en train de prétendre qu'on ne peut pas utiliser OpenBSD comme machine de bureau, mais plutôt que tout comme c'est inutile de conduire un 4x4 en centre ville, c'est déraisonnable de mettre un débutant complet devant OpenBSD sous prétexte que c'est super sécurisé.
Tu remarquera d'ailleurs que des distributions Linux existent déjà avec la philosophie OpenBSD, et que la plupart disposent d'une installation minimale ou/et de type "serveur" limitant les programmes installés par défaut.
Pour conclure, je dirais qu'une des plus grandes contributions d'OpenBSD au libre, c'est d'avoir fait prendre conscience aux gens comme toi et moi que la sécurité se joue autant à la conception qu'au déploiement des systèmes.
# Confusion
Posté par Guillaume POIRIER . En réponse au journal Nouveau Logo pour Kerrighed. Évalué à 5.
Pas du tout, efface!
C'est un patch au noyau Linux permettant de le transformer en système d'exploitation distribué.
A ce que j'ai compris, il permet un contrôle plus fin des processus qu'OpenMosix (qui permettait juste de migrer des processus entiers d'une machine à une autre), alors qu'ici, si je n'abuse, on peut distribuer au niveau thread (attention, je ne suis pas spécialiste).
Développé dans l'équipe Paris de l'IRISA de Rennes, son but premier est de permettre le calcul sur grappe, mais il doit permettre probablement bien plus.
Pour revenir au logo, je le trouve très réussi.
[^] # Re: Licences
Posté par Guillaume POIRIER . En réponse à la dépêche KDE doit-il abandonner KHTML pour Webcore ?. Évalué à 10.
Sans vouloir trouver des excuses à Apple, il se trouve qu'il est généralement difficile de faire collaborer des équipes de devs qui travaillent sur leur temps libre (et n'ont pas d'obligation de résultat) et des gens qui bossent dessus à temps plein et doivent sortir du produit au bout.
J'en veux pour preuve la quantité de patchs non appliqués par manque de temps dans le projet MPlayer: les contributions extérieures ne sont pas toujours dans la droite ligne du projet, et ne plaisent pas toujours à l'équipe de dévelloppement, tels qu'elles sont implémentées.
Par exemple, le projet Unichrome, qui ajoute le support des puces graphiques VIA existe depuis pas mal de temps, et a été plusieurs fois rejetté parceque le patch touchait à beaucoup de choses à la fois, certaines de ces modifications étant par ailleurs inutiles.
Si on regarde du côté de GCC, Apple a aussi sa version de GCC qui fonctionne diablement mieux pour générer du code Altivec que le GCC "normal". Or, toutes ces modifications ne se sont pas non plus retrouvées dans le "vrai" GCC pour les même raisons exposées plus haut.
Bref, Apple ne respecte pas tellement l'idéologie, mais on ne peut pas dire non plus que ça soit évident de contenter tout le monde
J'aurais été curieux de voir ce qu'aurait donné une collaboration "à la Red Hat": ie: embaucher les gens du projet pour le faire avancer suivant sa volonté.
Ca marche avec RedHat, mais c'est une entreprise d'inspiration libre depuis le début.
Apple, c'est différent, ils ont toujours été très secret sur leur façon de fonctionner... bah, peut-être qu'il faut leur laisser un peu de temps... Un virage à 180°, ça se négocie par trop vite, sinon on se casse la gueule...
[^] # Re: EarlyUserspace?
Posté par Guillaume POIRIER . En réponse au journal Ubuntu - The Breezy Badger. Évalué à 5.
En effet, le kernel n'est pas forcément préemptible, ce qui fait que quand par exemple il accède au matériel pour prendre connaissance des périphériques sur lequel il tourne, il me semble que le kernel passe pas mal de son temps à attendre que le matériel réagisse.
Avec un kernel préemptible, normalement on peut gagner un peu de temps de ce côté-là.
Par contre, il faut bien voir que déplacer des traitements en espaces utilisateurs, ça donne uniquement une illusion que ça aille plus vite, puisqu'au final, les traitement devront quand même être réalisés d'une manière ou d'une autre. Si on prend Windows XP par exemple, on arrive très vite sur le bureau, mais c'est pas pour autant qu'on peut déjà commencer à travailler, puisqu'une ribambelles de programmes sont encore en train de se charger.
[^] # Re: EarlyUserspace?
Posté par Guillaume POIRIER . En réponse au journal Ubuntu - The Breezy Badger. Évalué à 10.
L'exemple qu'il donnent, devfs est assez parlant: ce mordeau de code était tout moche, souffrait de bugs que personne ne voulait corriger justement à cause de la qualité du code, et en plus, n'était pas particulièrement rapide.
Cela a été remplacé par udev, que tout le monde connait, et qui donne suffisament satisfaction pour que presque toutes les distribs l'utilisent à présent.
Un autre exemple que je vois, c'est libata (j'espère que ne ne dis par de bêtise)
Mon avis là-dessus, c'est que finalement, Tanenbam n'avait pas tellement tord... :-)
[^] # Re: La solution !
Posté par Guillaume POIRIER . En réponse au journal Convertir une vidéo en DV ?. Évalué à 4.
Où là! C'est pas forcément une bonne idée de faire un encodage avec lavc sans rajouter quelques options demandant à l'encodeur d'optimiser un peu plus pour la qualité.
Voir ici pour les options qui ont un grand impact sur la qualité:
http://mplayerhq.hu/DOCS/HTML/en/menc-feat-dvd-mpeg4.html#menc-feat(...)
Sinon, le reste du guide d'encodage de MEncoder devrait de donner des bonnes bases pour faires des encodages de qualité.
NB: l'équipe de traduction de MPlayer recherche des volontaires pour traduire en français les dernières mises à jour de la page citée ci-dessus
[^] # Re: une piste ?
Posté par Guillaume POIRIER . En réponse au journal Convertir une vidéo en DV ?. Évalué à 3.
Il me semble que du pcm (c'est à dire wav) devrait fonctionner. A ma connaissance, le son n'est pas compressé dans les fichiers dv.
A part ça, si tu as encore des problèmes d'exports avec libdv, essaye de voir si tu peux pas générer un fichier 'mjpeg' (c-à-d une suite de jpeg).
MEncoder doit faire ça, sinon y'a aussi les "mjpeg tools" que j'ai utilisé et qui fonctionnent vraiment très bien.
On peut difficilement faire plus standard, et c'est il me semble le format de données qu'utilisent tous les éditeurs non linéaires de vidéo.
Bonne chance.
[^] # Re: ...
Posté par Guillaume POIRIER . En réponse au journal FreeBSD reiserfs :). Évalué à 4.
A ma connaissance, il n'y a que UFS et UFS + Soft Updades, qui ils me semblent sont l'équivalent (en mieux :) ) de ext3fs par rapport à ext2fs.
FAT doit bien sûr être supporté.
Plus d'infos sur les Soft Updates: http://www.huihoo.com/freebsd/handbook/configtuning-disk.html#SOFT-(...)
[^] # Re: Manque d'outil de configuration du système
Posté par Guillaume POIRIER . En réponse au journal Mandriva vs Ubuntu. Évalué à 3.
Ubuntu étant basé sur Gnome, je pense que l'environnemejt KDE a reçu moins d'attention.
As-tu essayé kubuntu peut-être?
Peut-être que les sources de paquets sont les mêmes de toutes façons, et que ça ne change rien, je sais pas...
# Tout comme avec les travaux communautaires...
Posté par Guillaume POIRIER . En réponse au journal Reflexions sur wikipedia comme support pédagogique. Évalué à 5.
Cela dit, je pense que c'est un risque qu'on court aussi quand on utilise des logiciels libres: il faut un minimum faire confiance à ses auteurs.
Il existe, au moins au niveau des logiciels libres, quelques gardes-fous: tout le monde n'a pas un accès en écriture au CVS, ou au site web.
De la même façon, il me semble que le contenu deu wikipedia passe par une sorte de modération ou comité de relecture avant d'être disponible.
Je pense par exemple à "l'affaire Pierre Tramo" VS Wikipedia, qui a conduit, je pense, à certaines restrictions sur les articles distribués.
Cela permet, je pense de diminuer les risques, mais ça reste une question de confiance (les modérateurs peuvent toujours péter les plombs).
# Des journaux comme ça...
Posté par Guillaume POIRIER . En réponse au journal Première photo d'une planète extrasolaire confirmée !. Évalué à 8.
C'est clair, enjoué et complet, et ça change des sujets habituels.
Dommage qu'on ne puisse pas plusser les journaux.
Je voudrais juste ajouter un truc: il existait une autre méthode pour détecter les exoplanètes avec des télescope terrestres "normaux" (c-à-d pas des bijoux comme le VLT), c'est la détection par "éclipse":
On suit l'éclat d'une étoile, sa forme, et si son éclat change et/ou qu'on voit une forme passer devant, c'est qu'elle doit avoir une planète à graviter autour.
L'intérêt, c'est que la planête n'as pas formément besoin d'être proche, mais là encore la planète doit faire plusieurs fois la taille de jupiter pour qu'on puisse la voir.
# Un autre benchmark intéressant ICC VS GCC -3.x et 4.0
Posté par Guillaume POIRIER . En réponse au journal GCC 4.0 et 3.4 et optimisations SSE. Évalué à 4.
On y apprend que GCC n'est pas ridicule lorsqu'il n'est pas utilisé sur une plateforme Intel, et qu'apparemment les binaires obtenus avec ICC sont capables de se saborder eux-même s'ils sont exécutés sur une plateforme non-intel:
C'est vraiment diabolique, d'autant qu'on peut se demander ce qui se passera quand on voudra exécuter le même binaire sur les nouveaux Pentium XX, et que la détection de la plateforme échouera probablement.
Rien que pour ça, ça vaut le coup de préférer GCC! ;-)
# Ubuntu Hoary
Posté par Guillaume POIRIER . En réponse au journal Debian et AMD64 ou en est on?. Évalué à 2.
Moi, j'ai une Ubuntu, et tout marche nikel "out of the box". OOo, firefox (sans flash, mais c'est un plus mal), drivers Nvidia.
Je ne sais pas si certaines de ces applis sont en 64bits on non, et de toute façon, je m'en fiche, c'est pas là que les gains se trouvent.
Par contre, niveau encodage, le 18% de speed-up avec tant x264 qu'XviD que libavcodec est plus qu'agréable, d'autant que c'est gratuit.
Maintenant, je comprendrais que tu n'aies pas envie de prendre une Ubuntu si tu veux absolument un support Debian "officiel", il n'en reste pas moins que c'est la solution la plus proche de ce que tu demandes, et qui fonctionne vraiement bien.
[^] # Re: À quand son utilisation partout ?
Posté par Guillaume POIRIER . En réponse à la dépêche Sortie de GCC 4.0. Évalué à 4.
Pourrais-tu en siter quelques-unes?
Je n'en ai jamais rencontré (avec 3.4, parceque avec le CVS de la 4.0, c'était déjà plus folklo)...
[^] # Re: À quand son utilisation partout ?
Posté par Guillaume POIRIER . En réponse à la dépêche Sortie de GCC 4.0. Évalué à 1.
Dans les cas d'utilisations courants, GCC 2.95 n'a pas à rougir de GCC 3.x. Il est bien plus rapide que la série 3.x, pour des performances proches.
# A pas mesurés
Posté par Guillaume POIRIER . En réponse à la dépêche Le développement du noyau continue autour de Git. Évalué à 5.
Les progrès se font donc à pas mesurés. Pour le moment, les fusions de branches de dévelloppement n'ont été testés que dans des cas simple, où il n'y a pas de conflit.
Là où BitKeeper excelle, il me semble, c'est en ce qui concerne la fusion plus problématique de branches entre les développeurs.
Ne nous entousasmions donc pas trop vite, le plus dure reste à venir... mais c'est clair que vu la vitesse à laquelle progresse git, je ne serais pas étonné qu'ils arrivent à relever le défit bien vite...
D'ailleurs en passant, sur la même page, on peut voir:
Un beau pied de nez à tous ceux qui ont décrié le nouveau mode de développement du kernel Linux.
Il permet bel et bien d'intégrer des avancées technologiques bien plus vite que par le passé.
... maintenant, qu'en est-il au niveau stabilité, j'en sais trop rien, mais chez moi, ça marche (TM).
[^] # Re: Numéro de version
Posté par Guillaume POIRIER . En réponse à la dépêche MPlayer 1.0pre7 "PatentCounter" dans les bacs. Évalué à 8.
FOR THE v1.00 RELEASE:
~~~~~~~~~~~~~~~~~~~~~~
- display OSD and subtitles using DVB card's OSD
mpg demuxer:
- implement mpeg-TS demuxer
- implement common mpeg 1/2/4 es/ps/pes/mp3 demuxer
avi demuxer: (needs rewrite)
- implement hardcore bruteforce avi re-sync for broken files (-forceidx)
- fix for growing avi files (movi_end pos > stream->end_pos)
- implement forward seeking in avi streams with no index
mencoder:
- finish mencoder -ovc vfw (bitrate setting, codec selection etc)
- add ogg/vorbis audio encoder
- stop/resume
DOCS:
- break up 6 level deep sections
- merge tech/encoding-tips.txt into mencoder.xml
- merge iive's XvMC docs into video.xml
- finish reviewing all of the docs
- mplayer.1
- encoding.html
- video.html
- documentation.html
- enhance the FAQ
- document missing XviD options
- add Matroska, NSV and nut to formats.xml
- split man page into mplayer.1 and mencoder.1
FUTURE:
~~~~~~~
demuxer:
- demux_mpg: support for VDR's index files for more accurate seeking
- implement seeking for YUV4MPEG_2_
decoders:
- fix DLLs: pegasusm, pegasusl, pegasusmwv, 3ivX, morgands, alaris, vcr1, pim1,
rricm
other:
- dvd server
- mga_vid crtc2 fix
- X11 Render support into DGA for OSD (from the DOCS;)
DOCS:
- convert man page to XML
- write a detailed encoding guide
- document missing divx4opts (everything in #if ENCORE_MAJOR_VERSION >= 5200,
vbrdebug)
Or il se trouve qu'un certain nombre de ces fonctions sont non triviales à implémenter, alors...bah oui, ça peut, dans la mesure où beaucoups de nouvelles killer features sont proposées par des codeurs externes (qui ne font pas partie des objectifs du TODO), et que seuls les gens de la core team essayent d'atteindre les objectifs de la 1.0 puisque ça nécessite des changements plus important.
En gros, c'est le problème du Bazaar: tout le monde peut proposer son travail dans la mesure où il a de l'intérêt, mais ça fait pas forcément avancer fondamentalement le projet (vers la 1.0).
Tu me suis? :-)
[^] # Re: codec libre?
Posté par Guillaume POIRIER . En réponse à la dépêche MPlayer 1.0pre7 "PatentCounter" dans les bacs. Évalué à 6.
C'est un des grands problèmes de l'informatique AMHA: que pourra-t-on faire de nos données dans le futur?
C'est tout l'intérêt, en effet des implémentations libres.
Par contre, sur le principe, ce n'est pas une bonne idée de ré-encoder parceque tu risques de re-compresser des artefacts de compression du fichier source.
Un peu comme si tu faisais un photocopie de photocopie en somme.
Mais c'est sûr que quand on n'a pas le choix...
Certains seraient tentés de te dire Théora+Vorbis. Le problème, c'est que ce n'est pas si bien supporté que ça, et qu'il n'y a pas de grosse communauté de developpeurs derrière.
Par contre, il n'y a pas de problèmes de brevets puisque On2, la société qui détient les brevet, à juré de ne rien faire à l'encontre de Théora.
En ce qui me concerne, j'utilise plutôt XviD+Vorbis, que je connais bien, et qui est bien supporté.