tag:linuxfr.org,2005:/users/gomgomLinuxFr.org : les contenus de Edouard Gomez2008-03-25T11:00:00+01:00/favicon.pngtag:linuxfr.org,2005:News/238932008-03-25T11:00:00+01:002008-03-25T11:00:00+01:00Mercurial 1.0<div>Après plus de trois ans de développement, Matt Mackall, développeur principal de Mercurial, annonce sur la liste de développement du projet que la version 1.0 est enfin prête. Mercurial est un gestionnaire de source décentralisé écrit en Python dont les objectifs principaux sont :
<br />
<ul><li>Facile à maîtriser et utiliser ;
<br />
</li><li>Léger ;
<br />
</li><li>Bonne tenue en charge (« scalabilité ») ;
<br />
</li><li>Facile à personnaliser.
<br />
</li></ul>Il est livré avec une excellente documentation qui permet bien sûr de découvrir l'ensemble des commandes du programme mais aussi de mieux appréhender la gestion de source décentralisée avec ses nombreux avantages. Ce gestionnaire fonctionne à la fois sous nos Unix préférés et sous Windows. Il intègre de plus un convertisseur de dépôt de source permettant de reprendre l'historique de ses anciens projets CVS, SVN, Git, Darcs, Monotone, et GNU Arch/Bazaar 1.x.
<br />
<br />
Laissez-vous tenter par cet excellent outil qui ne pêche que par le manque de publicité qu'il génère face à Bazaar ou Git.</div><ul><li>lien nᵒ 1 : <a title="http://www.selenic.com/pipermail/mercurial/2008-March/018014.html" hreflang="en" href="https://linuxfr.org/redirect/56551">L'annonce de la 1.0</a></li><li>lien nᵒ 2 : <a title="http://www.selenic.com/mercurial/" hreflang="en" href="https://linuxfr.org/redirect/56552">Homepage</a></li><li>lien nᵒ 3 : <a title="http://www.selenic.com/mercurial/wiki/index.cgi/Download" hreflang="en" href="https://linuxfr.org/redirect/56553">Téléchargement</a></li><li>lien nᵒ 4 : <a title="http://hgbook.red-bean.com/" hreflang="en" href="https://linuxfr.org/redirect/56554">La documentation</a></li><li>lien nᵒ 5 : <a title="http://marc.info/?l=linux-kernel&m=111399201508521&w=2" hreflang="en" href="https://linuxfr.org/redirect/56555">La naissance du projet</a></li></ul><div>Voici un peu plus de détail concernant les fonctionnalités de Mercurial.
<br />
<b>Rapide</b>
<br />
<ul><li>Grande rapidité grâce à son format de stockage orienté delta-compression ;
<br />
</li><li>Optimisé pour des accès rapides ;
<br />
</li><li>Indexation croisée des changesets et fichiers ;
<br />
</li><li>Protocoles HTTP et SSH optimisés en terme de bande passante et charge processeur.
<br />
</li></ul><b>Tenue en charge (« Scalable »)</b>
<br />
<ul><li>Le modèle de développement distribué supporte un nombre illimité de développeurs ;
<br />
</li><li>Permet la fusion arbitraire du travail de plusieurs développeurs ;
<br />
</li><li>Son niveau de performance ne se dégrade pas avec un grand nombre de fichiers ou changesets ;
<br />
</li><li>Pas d'attente sur verrou posé.
<br />
</li></ul><b>Robuste</b>
<br />
<ul><li>Garantie d'intégrité des données du dépôt de source grâce à l'utilisation de sommes de contrôle SHA1 ;
<br />
</li><li>Modèle de stockage « Append-only » avec un journal de transaction ;
<br />
</li><li>Vérification du dépôt de source rapide ;
<br />
</li><li>Format de stockage facilitant les sauvegardes.
<br />
</li></ul><b>Facile à utiliser</b>
<br />
<ul><li>Ceux maîtrisant déjà CVS ou un autre gestionnaire de source, connaissent sûrement déjà la plupart des commandes ;
<br />
</li><li>Aide en ligne intégrée ;
<br />
</li><li>Fournit une interface web indépendante ;
<br />
</li><li>Fonctionne avec plusieurs interfaces graphiques (TortoiseHG sous Windows par exemple).
<br />
</li></ul><b>Facile à mettre en place</b>
<br />
<ul><li>Compatible UNIX, Mac OS X, et Windows ;
<br />
</li><li>Plugin de conversion pour les gestionnaires de sources les plus communs ;
<br />
</li><li>Permet des modèles d'usage variés ;
<br />
</li><li>Supports de « hooks » et extensions définis par l'utilisateur.
<br />
</li></ul><b>Libre</b>
<br />
<ul><li>Source disponible sous la GPL v2 ;
<br />
</li><li>Soutenu et développé par une communauté active.
<br />
</li></ul>Mais rien n'est plus parlant que la liste grandissante de projets qui n'hésitent pas à basculer sous ce gestionnaire de sources :
<br />
<ul><li>La plupart des projets de chez Sun : OpenJDK, OpenSolaris, etc. ;
<br />
</li><li>Mozilla ;
<br />
</li><li>Des sous-projets du noyau: ALSA (pilotes son), LinuxTV (pilotes TV).
<br />
</li></ul>Alors oui, Mercurial n'est pas aussi exposé médiatiquement que Git ou Bazaar mais avec cette dépêche, j'espère que certains d'entre vous prendront le temps de découvrir Mercurial, de le comparer et donc de l'adopter :-).
<br />
<br />
N'oubliez pas de faire un tour sur le Wiki pour en savoir plus.</div><div><a href="https://linuxfr.org/news/mercurial-10.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/23000/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/news/mercurial-10#comments">ouvrir dans le navigateur</a>
</p>
Edouard Gomezhttps://linuxfr.org/nodes/23000/comments.atomtag:linuxfr.org,2005:Diary/191072005-08-16T10:39:31+02:002005-08-16T10:39:31+02:00Tom Lord abandonne GNU ArchTom Lord, mainteneur de GNU Arch, un programme de gestion de sources, a décidé d'abandonner le poste de mainteneur de GNU Arch.<br />
<br />
Pour ma part, je pense que Tom Lord a été un frein pour le projet. Il s'est souvent dispersé dans des projets aux objectifs mal définis (forth, son wiki etc...). Il a pris en hôtage GNU Arch à plusieurs reprises, en refusant sa prise en main par d'autres mainteneurs volontaires et soucieux de l'avenir du projet. Il a aussi souvent laissé de coté des patchs importants.<br />
<br />
Enfin, Tom Lord est un personnage à part entière, il n'est pas plus méchant que la moyenne, c'est juste qu'il a son caractère :-)<br />
<br />
Le post sur la mailing list:<br />
<a href="http://article.gmane.org/gmane.comp.version-control.arch.devel/1516">http://article.gmane.org/gmane.comp.version-control.arch.devel/1516(...)</a><br />
<br />
Même ce mail de départ est quelque peu empreint de sujets polémiques... ahhhhh jusqu'au bout... :-)<br />
<br />
Il est quand même plutôt fair play en souhaitant faire de bazaar la nouvelle branche GNU de arch. En effet, suite aux problèmes d'évolution de GNU Arch, Canonical (la boite derriere la Ubuntu) avait choisi de forker GNU Arch pour maintenir son pool de packages. L'objectif de bazaar était de refondre l'UI plutôt touffue de GNU Arch pour en faire quelque de plus simple. Cet objectif a ensuite évolué pour toucher à des choses plus profondes et plus primordiales.<br />
<br />
Enfin, bonne chance à Tom Lord pour ces futurs projets.<div><a href="https://linuxfr.org/users/gomgom/journaux/tom-lord-abandonne-gnu-arch.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/45642/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/users/gomgom/journaux/tom-lord-abandonne-gnu-arch#comments">ouvrir dans le navigateur</a>
</p>
Edouard Gomezhttps://linuxfr.org/nodes/45642/comments.atomtag:linuxfr.org,2005:Diary/188812005-07-20T15:25:57+02:002005-07-20T15:25:57+02:00L'âge moyen d'une ligne de code d'XviDLe fait d'exporter xvidcore vers un dépôt de source Mercurial (voir mon précédent journal) m'a permis de sortir des stats sur l'âge moyen d'une ligne de code du projet.<br />
<br />
Le projet est a 25% constitué de code provenant du premier patchset de la branche devapi4 (branche forké a partir de la version 0.9.0). Je me suis un peu senti vexé par cette statistique qui semble signifier qu'on s'est un peu branlé la nouille sur le projet depuis, car on a touché qu'a 75% du code source depuis la patchset 0.<br />
<br />
J'ai un peu modifié Mercurial pour me sortir des temps Unix dans la sortie de la commande log, et j'ai donc calculé l'âge moyen d'une ligne de code (c|asm|h) d'xvid. Le résultat est sans appel:<br />
Thu Jun 3 21:13:20 2004<br />
<br />
XviD a drôlement peu évolué depuis le cycle de versions 1.0.x. J'en suis d'autant plus touché que j'ai quitté ce projet en Janvier il me semble, et que depuis, c'est un peu le néant coté commit. Il semblerait que les développeurs restant ne font plus rien. Plutôt dommage étant donné que le projet est intéressant et que le travail ne manque pas.<br />
<br />
Addendum: les scripts me permettant de déduire l'âge moyen d'une ligne de code.<br />
<br />
<code><br />
# Annoter toutes les lignes.<br />
$ (for i in `hg manifest |grep -E "\.(c|h|asm)$" | awk '{print $3 }'` ; do hg annotate $i |cut -d ':' -f 1 ; done ) > annotations.txt<br />
<br />
# Chopper la date de chaque commit (j'ai patché mercurial/commands.py pour me donner un temps unix au lieu de time.asctime)<br />
$ hg log | grep ^date: | awk 'BEGIN{i=0;} { printf("date[%3s] = %s;\n", i, $2); i++;}' |less > patches-date.dat<br />
<br />
# Ecrire le script awk qui va faire le calcul<br />
$ cat > losc-age.awk << EOF<br />
BEGIN {<br />
EOF<br />
<br />
$ cat patches-date.dat >> losc-age.awk<br />
$ cat >>losc-age.awk << EOF<br />
for (i=0; i<444; i++) {<br />
patch[i] = 0;<br />
}<br />
average = 0;<br />
lines=0<br />
}<br />
<br />
{<br />
patch[$1]++;<br />
lines++;<br />
}<br />
<br />
END {<br />
for (i=0; i<444; i++) {<br />
average += patch[i]*date[i]/lines;<br />
}<br />
printf("%s\n", average);<br />
}<br />
EOF<br />
<br />
# Et on trouve l'age moyen<br />
$ awk -f losc-age.awk annotations.txt<br />
</code><br />
<br />
La date obtenue n'est pas super précise (erreur d'arrondi flottant), mais ça permet de donner au moins le triplet année/mois/jour moyen sans trop d'incertitude.<br />
<br />
<br />
Biensûr tout ceci aurait pu être fait en Python, mais je ne connais pas Python :-)<br />
<br />
<br />
Mon dépôt xvid converti utilisé pour ce test est disponible sur <a href="http://ed.gomez.free.fr/vrac/xvidcore-mercurial.tar.bz2">http://ed.gomez.free.fr/vrac/xvidcore-mercurial.tar.bz2(...)</a><div><a href="https://linuxfr.org/users/gomgom/journaux/l%C3%A2ge-moyen-dune-ligne-de-code-dxvid.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/45421/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/users/gomgom/journaux/l%C3%A2ge-moyen-dune-ligne-de-code-dxvid#comments">ouvrir dans le navigateur</a>
</p>
Edouard Gomezhttps://linuxfr.org/nodes/45421/comments.atomtag:linuxfr.org,2005:Diary/187362005-07-05T16:44:28+02:002005-07-05T16:44:28+02:00Mercurial, un autre SCM qui se cherche une placeHello journal,<br />
<br />
Même si j'ai été obligé de me vendre dans les forums pour gagner des XP et pouvoir poster ce journal... je t'en veux pas trop de m'avoir bouder en m'empêchant de te parler.<br />
<br />
Bref tout cela pour dire que j'ai continué à tester des SCM depuis mon dernier journal. La victime suivante a été Mercurial (<a href="http://www.selenic.com/mercurial).">http://www.selenic.com/mercurial).(...)</a><br />
<br />
C'est un sympathique projet en Python qui basé sur les mêmes idées que GIT (de linus torvalds) tente de réparer des erreurs de design fondamentales<br />
- c'est pas un modèle de portabilité (il y auraient de flagrant linuxismes)<br />
- les objets du backend nommés par le sha1 de leur contenu tend à pourrir les perfs lors des tree traversing de source. Cette baisse de perfs est due au fait que le backend en deux niveaux (un niveau de répertoire qui donne le début du hash sha1 et le nom complet de l'objet sha1 ensuite) tend à éloigner physiquement sur le disque des fichiers proches par leur localité dans l'arborescence logique.<br />
- n'est pas un SCM en soi, pour espérer pouvoir s'en sortir, il faut cogito, un sur-ensemble à GIT qui permet de s'en servir de façon conviviale.<br />
- consomme trop d'espace disque pour la taille d'un projet comme linux (3.6GB pour l'historique de linux depuis le 2.4.0). Ceci rend impossible l'import de l'historique global par tout le monde sans plomber kernel.org. Linus a décidé de ne publier l'historique que depuis le 2.6.12-rc2 pour remédier à ça. Mais même comme ça kernel.org a du mal à supporter la charge imposée par des synchros rsync.<br />
- et d'autres dont je suis moins sûr, donc autant éviter l'impression de linchage qui n'est absolument pas mon but.<br />
<br />
Donc mercurial a corrigé tout ça. Certains algos trop coûteux de GIT ont été écartés dans le design, et Mercurial a favorisé deux choses:<br />
- le cross indexing entre les revisions de fichiers et les changesets, ce qui rend extrêmement efficace la navigation dans les versions (pratique pour les opérations d'annotations, de diff entre 2 versions arbitraires, et de recherche d'ancêtre lors de merges)<br />
- backend qui respecte l'arborescence logique et qui enregistre les modifs de façon incrémentale et non pas sous la forme d'objets complets.<br />
- protocole assez efficace pour synchroniser deux repositories (basé sur HTTP).<br />
<br />
Avec ça on arrive à:<br />
- historique de linux depuis le 2.4.0: 309MB<br />
- clone d'un repo linux comprenant l'historique complet: ~130MB transférés.<br />
- et pleins d'autres trucs impressionnants comme des diffs super rapides, des imports de patch rapides, des annotations peu coûteuses etc... (pour des chiffres sur l'importation de patchs voir <a href="http://www.selenic.com/pipermail/mercurial/2005-June/001498.html">http://www.selenic.com/pipermail/mercurial/2005-June/001498.html(...)</a> )<br />
<br />
Pour le coup j'ai amélioré mon script d'export arch vers "autre SCM" maison (sans prétention, y a un projet Python qui ferait beaucoup mieux d'apres ce j'ai cru en lire mais manque de bol, il supporte pas arch. Ca s'appelle tailor). Le repository obtenu est dispo la: <a href="http://ed.gomez.free.fr/vrac/xvidcore-mercurial.tar.bz2">http://ed.gomez.free.fr/vrac/xvidcore-mercurial.tar.bz2(...)</a> , le script dont je me suis servi est la: <a href="http://ed.gomez.free.fr/vrac/convert-xvid-baz-repo-to-mercurial.sh">http://ed.gomez.free.fr/vrac/convert-xvid-baz-repo-to-mercurial.sh(...)</a> .<br />
<br />
Bon je m'arrête là, je vous laisse découvrir l'outil par vous même.<div><a href="https://linuxfr.org/users/gomgom/journaux/mercurial-un-autre-scm-qui-se-cherche-une-place.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/45277/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/users/gomgom/journaux/mercurial-un-autre-scm-qui-se-cherche-une-place#comments">ouvrir dans le navigateur</a>
</p>
Edouard Gomezhttps://linuxfr.org/nodes/45277/comments.atomtag:linuxfr.org,2005:Diary/178292005-04-14T17:30:15+02:002005-04-14T17:30:15+02:00Arch vers MonotoneSuite a l'episode BK sur la LKML, je me suis dit que je pouvais retenter d'utiliser monotone car ça fait maintenant 3ans que j'utilise arch/tla (baz aujourd'hui), et je m'encroute dans mes habitudes.<br />
<br />
J'ai donc pour tester le bignou, pris le projet XviD depuis Janvier 2004 que j'ai maintenu dans mes archives arch (dispos sur mon site)<br />
<br />
En gros j'ai fait, deux scripts de porc:<br />
<br />
Le premier importe la base head de 2004:<br />
<pre><br />
#!/bin/sh<br />
# ---- Initial import ----<br />
<br />
baz get ed.gomez@free.fr--2004-1/xvidcore--head--0.0--base-0 xvidcore.baz<br />
monotone --db=xvidcore.monotone db init<br />
monotone --db=xvidcore.monotone genkey ed.gomez@free.fr<br />
cd xvidcore.baz<br />
monotone --db=../xvidcore.monotone setup .<br />
baz inventory -s | xargs monotone --db=../xvidcore.monotone add<br />
monotone --db=../xvidcore.monotone --branch=org.xvid.head commit --message="Initial import in monotone"<br />
</pre><br />
<br />
Le deuxieme permet de mettre a jour vers la revision suivante:<br />
<pre><br />
#!/bin/sh<br />
<br />
REVISION=$1<br />
<br />
baz replay ed.gomez@free.fr--2004-1/xvidcore--head--0.0--patch-${REVISION} | grep -v '{arch}' | grep -v '.arch-ids' | grep -v "^*" > replay.txt<br />
<br />
ADDED_FILES=`grep ^A[^/] replay.txt |awk '{print $2}'`<br />
MODIFIED_FILES=`grep ^M replay.txt |awk '{print $2}'`<br />
DELETED_FILES=`grep ^D[^/] replay.txt |awk '{print $2}'`<br />
RENAMED_FILES=`grep ^R replay.txt |awk '{print $2 ":" $4;}'`<br />
<br />
for i in ${ADDED_FILES} ; do<br />
monotone --db=../xvidcore.monotone add ${i}<br />
echo "A ${i}"<br />
done<br />
for i in ${DELETED_FILES} ; do<br />
monotone --db=../xvidcore.monotone drop ${i}<br />
echo "D ${i}"<br />
done<br />
for i in ${RENAMED_FILES} ; do<br />
ORG_FILE=`echo $i | cut -d ':' -f 1`<br />
DST_FILE=`echo $i | cut -d ':' -f 2`<br />
echo "R ${ORG_FILE} => ${DST_FILE}"<br />
monotone --db=../xvidcore.monotone rename ${ORG_FILE} ${DST_FILE}<br />
done<br />
for i in ${MODIFIED_FILES} ; do<br />
echo "M ${i}"<br />
done<br />
<br />
COMMIT_SUMMARY=` baz log -f -r patch-${REVISION}:patch-${REVISION} |grep ^Summary: | sed s,'^Summary:[[:space:]]*\(.*\)$','\1',`<br />
COMMIT_LOG=`baz log -f -r patch-${REVISION}:patch-${REVISION} | awk 'BEGIN{start=0} /^$/ {start=1;} // { if (start != 0) print;}' | grep -v '==========='`<br />
echo "Summary: ${COMMIT_SUMMARY}" > MT/log<br />
echo >> MT/log<br />
echo "${COMMIT_LOG}" >> MT/log<br />
</pre><br />
<br />
Puis je m'en suis servi comme ça:<br />
<pre><br />
# cd ~/tmp/<br />
# mkdir monotone.test<br />
# cd monotone.test<br />
# import-base.sh<br />
# cd xvidcore.baz<br />
# for i in `seq 1 121` ; do commit-rev.sh ${i} ; monotone --db=../xvidcore.monotone commit ; done<br />
# (edition de commit-rev.sh pour passer sur mon archive 2005)<br />
# baz replay ed.gomez@free.fr--2005-1/xvidcore--head--0.0--base-0<br />
# for i in `seq 1 8` ; do commit-rev.sh ${i} ; monotone --db=../xvidcore.monotone commit ; done<br />
</pre><br />
<br />
Avis de la transition:<br />
- J'ai pas encore vérifié la cohérence des révisions, je ne sais pas si elles sont équivalentes à celles de arch. Mais les commits ne m'ont pas semblé longuets, donc pour un projet de la taille d'xvid, monotone est utilisable sans souci sur ce point la.<br />
- En deux cuillères a pot, j'ai pu coder un script de migration arch>monotone qui conserve l'historique linéaire d'une branche avec tous les logs messages ! Pas mal, il faudrait cependant faire gaffe au type de changeset dans arch, s'il s'agit d'un merge, il faudrait idéalement importer la branche dont provient le merge avant de merger le patch, et utiliser monotone dans un contexte de merge histoire que l'arbre des révisions monotone ait la meme topologie que celui d'arch.<br />
- J'ai mal aux doigts a force de taper le password de mon certificat monotone et de faire :wq pour valider le log pourtant ecrit dans MT/log...<br />
<br />
En gros la 0.18 semble aussi sympa a utiliser que arch/baz, la prise en main est plus simple que celle d'un baz 1.3. Le seul point que je trouve dommage c'est le fait de ne pas pouvoir faire un mirror de sa DB locale sur un serveur tout bête HTTP ou FTP ou SFTP comme le fait arch, la on est obligé de lancer un serveur maison qui permet de synchroniser.<br />
<br />
Ah bonne surprise, monotone est plutôt bon à représenter les révisions sous forme compacte, les 130 révisions pèsent 1.5MB pour monotone alors que pour arch sur une partoche ext3, ca pèse 3MB, avec certes une révision en cache pour la continuation 2004->2005.<br />
<br />
Enfin voila, ma petite expérience avec monotone... au lieu de troller sur le thread BK, on pourrait donner ici ses expériences dans l'utilisation d'outils SCM décentralisés.<br />
<br />
PS: j'ai utilisé bazaar 1.3.1 et monotone 0.18 pour effectuer tout ça<div><a href="https://linuxfr.org/users/gomgom/journaux/arch-vers-monotone.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/44396/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/users/gomgom/journaux/arch-vers-monotone#comments">ouvrir dans le navigateur</a>
</p>
Edouard Gomezhttps://linuxfr.org/nodes/44396/comments.atomtag:linuxfr.org,2005:Diary/177092005-04-05T02:05:32+02:002005-04-05T02:05:32+02:00XviD 1.1.0-beta2 is out ! Et moi aussi...Houpla boum, une nouvelle release d'XviD.<br />
<br />
Pour ceux qui ne connaissent pas, il s'agit d'un codec MPEG4 libre (GPL) qui donne d'excellents résultats pour des taux de compression importants (<1.5MBit/s)<br />
<br />
Cette nouvelle version apporte un certain gain en qualité pour les vidéos à petit débit, et corrige certains bugs de la dernière beta. Le ChangeLog est disponible sur <a href="http://www.xvid.org/">http://www.xvid.org/(...)</a> ainsi que les sources.<br />
<br />
Cette release est aussi la dernière que je prépare au nom de la "XviD team", car après plus de 3 années de loyaux services, je ne ressens plus aucun plaisir à travailler sur ce projet qui demande beaucoup d'investissement personnel en temps pour le suivi et son amélioration.<br />
<br />
Voilà j'espère que les linuxfriens qui utilisent xvid et lisent ce journal ont apprécié mon travail. Je souhaite bonne chance au reste des developpeurs XviD pour les prochaines releases.<div><a href="https://linuxfr.org/users/gomgom/journaux/xvid-110-beta2-is-out-et-moi-aussi.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/44277/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/users/gomgom/journaux/xvid-110-beta2-is-out-et-moi-aussi#comments">ouvrir dans le navigateur</a>
</p>
Edouard Gomezhttps://linuxfr.org/nodes/44277/comments.atomtag:linuxfr.org,2005:Diary/165522004-12-29T09:54:48+01:002004-12-29T09:54:48+01:00Comparatif de codecs vidéo doom9 2004Et hop, le cru 2004 de comparaison de codec de Mr Doom9 vient de paraître.<br />
<br />
XviD a perdu la première place en faveur de codecs basés sur le standard mpeg4 avc, qui n'a de rapport avec le mpeg4 d'aujourd'hui (xvid, divx, ffmpeg-mpeg4) que le nom.<br />
<br />
Ce journal n'ayant pour objectif que de donner un peu de lecture à ceux que le codage vidéo intéresse, je ne m'étendrai pas sur les détails et vous laisse lire tout çà aidés vos petits "oeils" attentifs.<br />
<br />
Ca se passe par la:<br />
<a href="http://www.doom9.org/codecs-104-1.htm">http://www.doom9.org/codecs-104-1.htm(...)</a><br />
<br />
PS: je trouve dommage que ffmpeg ait été laissé de coté, il n'est même pas fait mention de lui une seule fois. Codec apparemment boudé par les utilisateurs de windows. Même remarque pour x264, codec libre basé sur le standard mpeg4 avc, standard qui a montré son fort potentiel dans ce comparatif.<div><a href="https://linuxfr.org/users/gomgom/journaux/comparatif-de-codecs-vid%C3%A9o-doom9-2004.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/43140/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/users/gomgom/journaux/comparatif-de-codecs-vid%C3%A9o-doom9-2004#comments">ouvrir dans le navigateur</a>
</p>
Edouard Gomezhttps://linuxfr.org/nodes/43140/comments.atomtag:linuxfr.org,2005:Diary/159362004-11-08T20:39:56+01:002004-11-08T20:39:56+01:00Tutoriaux sympathiques pour GIMP2Faisant suite à un de mes précédents journaux, j'ai déniché ces tutoriaux d'un fort beau gabarit. Ils ne correspondent pas à mes besoins, mais je me disais que çà pourrait rendre service à certains d'entre vous pour découvrir GIMP2.<br />
<br />
Les adresses:<br />
<a href="http://jimmac.musichall.cz/gimp2demos.php">http://jimmac.musichall.cz/gimp2demos.php(...)</a><br />
<a href="http://jimmac.musichall.cz/gimp2demos2.php">http://jimmac.musichall.cz/gimp2demos2.php(...)</a><br />
<br />
Bon apprentissage.<div><a href="https://linuxfr.org/users/gomgom/journaux/tutoriaux-sympathiques-pour-gimp2.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/42549/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/users/gomgom/journaux/tutoriaux-sympathiques-pour-gimp2#comments">ouvrir dans le navigateur</a>
</p>
Edouard Gomezhttps://linuxfr.org/nodes/42549/comments.atomtag:linuxfr.org,2005:Diary/158022004-10-28T01:15:39+02:002004-10-28T01:15:39+02:00Clin d'oeilPetit journal bien léger et totalement crétin, et inutile...<br />
<br />
J'ai trouvé une voiture qui porte la moitié de mon nickname en bannière latérale... si c'est pas la classe çà ! En plus garée juste devant chez moi. J'ai pas pu résister et j'ai l'ai prise en photo.<br />
<br />
<a href="http://ed.gomez.free.fr/vrac/pictures/gomgom-car.jpg">http://ed.gomez.free.fr/vrac/pictures/gomgom-car.jpg(...)</a><br />
<br />
D'ailleurs je serais soit disant un "nettoyeur"...<br />
<br />
:-) Bonne journée à tous<div><a href="https://linuxfr.org/users/gomgom/journaux/clin-doeil.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/42415/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/users/gomgom/journaux/clin-doeil#comments">ouvrir dans le navigateur</a>
</p>
Edouard Gomezhttps://linuxfr.org/nodes/42415/comments.atomtag:linuxfr.org,2005:Diary/156232004-10-12T13:48:04+02:002004-10-12T13:48:04+02:00Utilisation de GIMP pour de la photo numerique.Bonjour journal,<br />
<br />
Heureux possesseur d'un APN depuis quelques mois, je commence a bien connaître mon appareil et donc ses défauts. C'est pourquoi je tente de retoucher mes photos pour qu'elles collent plus à ce que je ressentais au moment de la prise en terme d'ambiance/lumière/contraste/grain.<br />
<br />
Sous GNU/Linux, mon sauveur s'appelle The Gimp, et j'ai trouvé d'excellents tutoriaux sur <a href="http://www.gimpguru.org/">http://www.gimpguru.org/(...)</a> et je voudrais aller encore un poil plus loin.<br />
<br />
Journal aurais tu d'autres adresses avec des tutoriaux orientés photo aussi intéressants car mon ami google me ramène toujours les mêmes tutoriaux de base :-( ?<div><a href="https://linuxfr.org/users/gomgom/journaux/utilisation-de-gimp-pour-de-la-photo-numerique.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/42240/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/users/gomgom/journaux/utilisation-de-gimp-pour-de-la-photo-numerique#comments">ouvrir dans le navigateur</a>
</p>
Edouard Gomezhttps://linuxfr.org/nodes/42240/comments.atomtag:linuxfr.org,2005:Diary/151692004-09-01T03:05:11+02:002004-09-01T03:05:11+02:00XviD 1.0.2 dans les bacsComment ça, mes journaux se ressemblent ?!... non pas possible ;-)<br />
<br />
L'équipe xvid a le plaisir d'annoncer une release mineure corrigeant quelques bugs (dont un majeur pour le décodeur *uniquement*, le codeur est conforme depuis la 1.0.0)<br />
<br />
* xvidcore<br />
- Correction d'un bug d'arrondi lors du décodage des bvops, ce bug rendait le décodeur non conforme au standard, bien que visuellement ce bug n'ait jamais aucun impact (les erreurs d'arrondis sont d'une amplitude de +1 sur la valeur des pixels, dur pour l'oeil de voir la différence).<br />
- Meilleur code de clipping des vecteurs dans le cas de flux codés cassés (erreur de transmission), le code ne devrait plus permettre de crashs.<br />
- Meilleur gestion des cas ou le flux codé "dit" ne pas contenir de bvops, mais en contient bien.<br />
- Les valeurs de fincr/fbase sont remises à echelle pour qu'elles ne dépassent jamais une longueur dépassant les 16bit autorisés par le standard.<br />
- Correction d'un petit problème de "thread safety" dans la version C de la fonction iDCT.<br />
<br />
* frontend vfw<br />
- correction d'une fuite memoire<br />
<br />
* répertoire debian:<br />
- rajouté au packaging de la release puisque xvidcore ne semble pas être accepté dans le pool debian :-( (sûrement à cause des brevets)<br />
<br />
En résumé, cette version n'apporte aucune fonctionnalité, juste des correctifs plus ou moins importants.<br />
<br />
Pour les gens désireux de tester du code frais et qui sens bon la fin d'été, il reste toujours l'option CVS HEAD, ou sur mon site, des snapshots plus ou moins réguliers (quand je trouve que c'est opportun). Qu'apporte la version HEAD:<br />
- nouveau port PPC (activé, bien que partiel)<br />
- des tonnes d'optims coté décodeur (25% de perfs en mieux, ffmpeg est toujours plus rapide mais j'y arriverai(tm))<br />
- des retouches coté codeur, et meilleure qualité pour les bvops (option bvhq=1, voir ma section 'modules mplayer')<br />
<br />
A noter que si vous jouez avec la version HEAD, c'est pour tester et donner des retours (merci bcp), pas pour se plaindre :-)<br />
<br />
Pour vos archivages sérieux, veuillez utiliser la version stable 1.0.2.<br />
<br />
Les liens qui vont bien:<br />
L'annonce: <a href="http://list.xvid.org/pipermail/xvid-devel/2004-August/004539.html">http://list.xvid.org/pipermail/xvid-devel/2004-August/004539.html(...)</a><br />
Pour la version stable <a href="http://www.xvid.org/">http://www.xvid.org/(...)</a> ou <a href="http://ed.gomez.free.fr/projects/xvid-1.0.2/">http://ed.gomez.free.fr/projects/xvid-1.0.2/(...)</a><br />
Pour les snapshots: le cvs sur <a href="http://www.xvid.org/">http://www.xvid.org/(...)</a> (developer->cvs) ou <a href="http://ed.gomez.free.fr/projects/xvid-snapshot/">http://ed.gomez.free.fr/projects/xvid-snapshot/(...)</a><br />
Pour le module mplayer mis à jour: <a href="http://ed.gomez.free.fr/#mencoder_modules">http://ed.gomez.free.fr/#mencoder_modules(...)</a><br />
Pour les chèques et les rendez vous coquins, s'adresser directement à mon agent.<br />
<br />
Merci pour votre attention.<br />
<br />
PS: vu que les journaux se voient amputés de tous les posts "comment je fais pour...?" (merci les forums), je me permets de passer tranquillement cette news en journal "Première Page".<div><a href="https://linuxfr.org/users/gomgom/journaux/xvid-102-dans-les-bacs.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/41807/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/users/gomgom/journaux/xvid-102-dans-les-bacs#comments">ouvrir dans le navigateur</a>
</p>
Edouard Gomezhttps://linuxfr.org/nodes/41807/comments.atomtag:linuxfr.org,2005:Diary/139922004-06-20T17:42:43+02:002004-06-20T17:42:43+02:00Hugin et enblend sur un bateau, l'un d'eux tombe à l'eau...Heureux possesseur d'un APN depuis un ou deux mois, j'ai donc eu moi aussi envie de faire des panoramiques a moindre frais :-)<br />
<br />
Mais bon je sais pas trop pourquoi, j'm'y suis pas mis. Et pourtant cykl (<a href="http://linuxfr.org/~cykl/">http://linuxfr.org/~cykl/(...)</a>) m'avais pointé vers hugin (<a href="http://hugin.sourceforge.net/">http://hugin.sourceforge.net/(...)</a>), site me pointant a son tour vers enblend (<a href="http://www-cad.eecs.berkeley.edu/~mihal/enblend/">http://www-cad.eecs.berkeley.edu/~mihal/enblend/(...)</a>)... mais non, j'ai pas fait de panos, donc je me suis pas penché sur ces programmes prometteurs.<br />
<br />
J'ai même vu traîner deux journaux linuxfr sur le sujet.<br />
<br />
Puis aujourd'hui (enfin hier pour être précis), je me suis dis, allez prend ton courage a deux mains, et installes le bouzin pour voir le resultat. Comme annoncé sur le site, c'est un cauchemar de dépendances, mais la je trouve "LA" adresse sympa pour les debianeux (<a href="http://people.debian.org/~jordens/debs/">http://people.debian.org/~jordens/debs/(...)</a>) et j'installe le tout avec un simple apt-get hugin enblend.<br />
<br />
J'ouvres ma fenêtre, prend trois photos vite fait, et lance hugin pour "stitcher" tout ca. Et la horreur ! enblend supporte pas les TIFF multilayer de hugin+stitcher nona... sur ce j'abandonne et je pleure sur ce resultat: <a href="http://ed.gomez.free.fr/vrac/plop-nonblended.jpg.">http://ed.gomez.free.fr/vrac/plop-nonblended.jpg.(...)</a><br />
<br />
Mais je me réveille ce matin archi motivé, et je me décide à patcher enblend, car extraire les layers à la mimine dans GIMP, c'est long fastidieux et ca devrait être le travail d'un programme informatique, pas de l'Homme :-)<br />
<br />
Alors du coup, je pond çà:<br />
<a href="http://ed.gomez.free.fr/vrac/multi-layered-tiff.diff">http://ed.gomez.free.fr/vrac/multi-layered-tiff.diff(...)</a><br />
<br />
Et je pleure de joie sur:<br />
<a href="http://ed.gomez.free.fr/vrac/plop-blended.jpg">http://ed.gomez.free.fr/vrac/plop-blended.jpg(...)</a><br />
<br />
Et je poste ca:<br />
<a href="http://www.email-lists.org/pipermail/ptx/2004-June/001791.html">http://www.email-lists.org/pipermail/ptx/2004-June/001791.html(...)</a><br />
<br />
Donc tout retour est le bienvenu de la part des linuxfr'iens.<br />
<br />
PS: il semble d'apres une reponse a mon post sur [ptx] que hugin possede un output multi TIFF que je n'ai pas vu... bon bé tant pis, quelqu'un pour confirmer ? sinon le patch c'est du benef :-)<br />
<br />
PPS: oui pas besoin de commenter sur la mocheté des banlieues parisiennes :P<div><a href="https://linuxfr.org/users/gomgom/journaux/hugin-et-enblend-sur-un-bateau-lun-deux-tombe-%C3%A0-leau.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/40672/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/users/gomgom/journaux/hugin-et-enblend-sur-un-bateau-lun-deux-tombe-%C3%A0-leau#comments">ouvrir dans le navigateur</a>
</p>
Edouard Gomezhttps://linuxfr.org/nodes/40672/comments.atomtag:linuxfr.org,2005:Diary/134822004-06-07T10:24:55+02:002004-06-07T10:24:55+02:00XviD 1.0.1Une nouvelle version de XviD est disponible. Il s'agit "juste" d'une version bugfix.<br />
<br />
Elle corrige quelques bugs mineurs qui rendaient le codage un poil sous optimal. Donc cette version peut apporter un gain en qualité.<br />
<br />
Coté décodeur, les vidéos de 1 image/seconde ne devraient plus poser de problèmes. (On y pense pas souvent à coder des vidéos en 1fps ;-)<br />
<br />
La news détaillée, les sources, l'argent, la gloire et la beauté sont dispos sur (pour les deux premiers c'est sûr et certain, les 3 autres, ça dépend du visiteur :-):<br />
<a href="http://www.xvid.org/">http://www.xvid.org/(...)</a><div><a href="https://linuxfr.org/users/gomgom/journaux/xvid-101.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/40162/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/users/gomgom/journaux/xvid-101#comments">ouvrir dans le navigateur</a>
</p>
Edouard Gomezhttps://linuxfr.org/nodes/40162/comments.atomtag:linuxfr.org,2005:News/162692004-05-18T19:44:05+02:002004-05-18T19:44:05+02:00XviD 1.0 est enfin sorti !<div>L'équipe de développement est heureuse de vous annoncer la disponibilité immédiate d'XviD 1.0.0. Et bien que ce numéro de version ne soit au final que symbolique, il s'agit tout de même d'une étape importante. La "xvid-team" espère que vous apprécierez les efforts placés dans cette version 1.0. Merci à tous les utilisateurs qui ont rapporté des bugs, envoyé des patchs et donc au final contribué à ce que XviD atteigne une qualité suffisante pour être estampillée 1.0.
<br />
<br />
Nous vous souhaitons d'heureux codages de vidéo et restez attentifs aux améliorations prévues pour les prochaines versions.
<br />
<br />
<b>Màj</b> : Pour fêter la sortie de XVid 1.0, le site s'est fait pirater. Mais le logiciel est toujours téléchargeable sur le site.
<br />
<br />
<i>NdM : rappelons que XviD est une implémentation libre - donc ouverte - du codec MPEG4. Ce qui ne gâche rien, c'est que XviD est aussi le meilleur codec MPEG4, c'est le site de référence Doom9 qui le conclut après de nombreux tests.
<br />
<br />
Guillaume POIRIER précise : XviD est un codec MPEG-4 libre supportant un grand nombre de fonctionnalités avancées de MPEG-4, telles que le GMC, les qpel, et dispose de quelques modes spéciaux pour l'encodage d'anime ou de films.
<br />
Cette version a vu bon nombre de nouvelles fonctionnalités s'ajouter, et la vitesse d'encodage s'accélérer, avec des optimisations SIMD pour PPC et pour x86, et une ré-écriture du code pour l'encodage en deux passes.
<br />
<br />
NdM 2 : merci à Freedom66, mansuetus et Guillaume POIRIER pour avoir également proposé la nouvelle.</i></div><ul><li>lien nᵒ 1 : <a title="http://www.xvid.org/" hreflang="en" href="https://linuxfr.org/redirect/34300">XviD.org</a></li><li>lien nᵒ 2 : <a title="http://ffmpeg.sourceforge.net/" hreflang="en" href="https://linuxfr.org/redirect/34301">Un ami/concurrent libre</a></li><li>lien nᵒ 3 : <a title="http://linuxfr.org/2003/12/31/14968.html" hreflang="fr" href="https://linuxfr.org/redirect/34307">DLFP 2003-12-31 : « Tests de codecs vidéo Doom9.org : XviD vainqueur »</a></li><li>lien nᵒ 4 : <a title="http://www.xvid.org/downloads.html" hreflang="en" href="https://linuxfr.org/redirect/34308">Téléchargements</a></li><li>lien nᵒ 5 : <a title="http://ed.gomez.free.fr/projects/xvid-1.0.0/" hreflang="en" href="https://linuxfr.org/redirect/34309">Sources signées par Edouard Gomez (xvid-team)</a></li><li>lien nᵒ 6 : <a title="http://ed.gomez.free.fr/gpg-key.txt" hreflang="en" href="https://linuxfr.org/redirect/34310">La clef publique GnuPG</a></li></ul><div>Changements depuis la RC4 (Hola):
<br />
- bug mineur dans l'optimisation de quantification par Trellis ;
<br />
- optimisation des modes VHQ> (le code exécutait deux types de recherches, là ou une seule était utile) ;
<br />
- meilleur clipping des vecteurs de mouvements ;
<br />
- correction de la fonction C de sortie RGB 16bit ;
<br />
- correction d'une possible corruption de l'entête VOL dans le cas ou le framerate est de 1 image par seconde ;
<br />
- correction de la prédiction du coefficient DC (ce bug a aussi été rapporté/corrigé au/par le projet FFMPEG).
<br />
<br />
Puis ma valeur ajoutée à cette traduction de l'annonce... XviD 1.0 c'est quand même:
<br />
- un projet vieux de 3ans (enfin en Novembre 2004), dont presque 1an et demi consacré à cette version ;
<br />
- un projet mené tant bien que mal par à peu près seulement 6 personnes de coins différents (Allemagne, France, Australie, USA et d'autres) ;
<br />
- quelques 242 patchs depuis la version 0.9.2, soit un patchset arch/tla pesant 5.2MB (logs tla compris), soit 93 fichiers modifiés, 525 fichiers ajoutés (logs tla compris), 50 fichiers supprimés, 18 fichiers renommés ;
<br />
- des heures et des heures de chauffage de pièce par les CPUs des devs pour les tests, et pas de pause pendant la canicule 2003 ;
<br />
- de belles tensions dans l'équipe de dev pour savoir ce qui a le droit de citer dans la version finale comme fonctionnalité ou encore license GPL ou license GPL plus clause d'exclusion géographique à cause des brevets logiciels.
<br />
<br />
Bah vala, il est temps de lâcher son bébé dans la nature, mon oeuvre ne m'appartient plus :-)</div><div><a href="https://linuxfr.org/news/xvid-10-est-enfin-sorti.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/15586/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/news/xvid-10-est-enfin-sorti#comments">ouvrir dans le navigateur</a>
</p>
Edouard Gomezhttps://linuxfr.org/nodes/15586/comments.atomtag:linuxfr.org,2005:Diary/128022004-05-17T00:00:29+02:002004-05-17T00:00:29+02:00Sortie de XviD 1.0.0Bonjour,<br />
<br />
Voici XviD 1.0.0<br />
<br />
L'équipe de développement est heureuse de vous annoncer la disponibilité immédiate d'XviD 1.0.0. Et bien que ce numéro de version ne soit au final que symbolique, il s'agit tout de même d'une étape importante. La "xvid-team" espère que vous apprécierez les efforts placés dans cette version 1.0. Merci à tous les utilisateurs qui ont rapporté des bugs, envoyés des patchs et donc au final contribuer à ce que XviD atteigne une qualité suffisante pour être estampillée 1.0.<br />
<br />
Nous vous souhaitons d'heureux codages de vidéo et restez attentifs aux améliorations prévues pour les prochaines versions.<br />
<br />
Changements depuis la RC4 (Hola):<ul><li>Bug mineur dans l'optimisation de quantification par Trellis</li><li>Optimisation des modes VHQ>1 (le code exécutait deux types de recherches, là ou une seule était utile)</li><li>Meilleur clipping des vecteurs de mouvements</li><li>Correction de la fonction C de sortie RGB 16bit</li><li>Correction d'une possible corruption de l'entête VOL dans le cas ou le framerate est de 1 image par seconde</li><li>Correction de la prédiction du coefficient DC (ce bug a aussi été rapporté/corrigé au/par le projet FFMPEG)</li></ul><br />
<br />
Dispo dans cette crèmerie uniquement, mais à savourer entre amis:<br />
<a href="http://www.xvid.org/">http://www.xvid.org/(...)</a><br />
<br />
-- XviD Team<br />
<br />
Puis ma valeur ajoutée à cette traduction de l'annonce... XviD 1.0 c'est quand même:<ul><li>un projet vieux de 3ans (enfin en Novembre 2004), dont presque 1an et demi consacré à cette version</li><li>un projet mené tant bien que mal par à peu près seulement 6 personnes de coins différents (Allemagne, France, Australie, USA et d'autres)</li><li>quelques 242 patchs depuis la version 0.9.2, soit un patchset arch/tla pesant 5.2MB (logs tla compris), soit 93 fichiers modifiés, 525 fichiers ajoutés (logs tla compris), 50 fichiers supprimés, 18 fichiers renommés.</li><li>des heures et des heures de chauffage de pièce par les CPUs des devs pour les tests, et pas de pause pendant la canicule 2003</li><li>de belles tensions dans l'équipe de dev pour savoir ce qui a le droit de citer dans la version finale comme fonctionnalité ou encore license GPL ou license GPL plus clause d'exclusion géographique à cause des brevets logiciels</li></ul><br />
<br />
Bah vala, il est temps de lacher son bébé dans la nature, mon oeuvre ne m'appartient plus :-)<br />
<br />
PS: pensant que linuxfr n'est pas freshmeat, je n'ai pas proposé cette info comme une news, si vous pensez le contraire, soumettez la donc, ca ne me deranges pas.<div><a href="https://linuxfr.org/users/gomgom/journaux/sortie-de-xvid-100.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/39518/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/users/gomgom/journaux/sortie-de-xvid-100#comments">ouvrir dans le navigateur</a>
</p>
Edouard Gomezhttps://linuxfr.org/nodes/39518/comments.atom