Journal : L'âge moyen d'une ligne de code d'XviD
Posté par Edouard Gomez (page perso, ) le 20 juillet 2005
Le 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.
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.
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:
Thu Jun 3 21:13:20 2004
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.
Addendum: les scripts me permettant de déduire l'âge moyen d'une ligne de code.
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.
Biensûr tout ceci aurait pu être fait en Python, mais je ne connais pas Python :-)
Mon dépôt xvid converti utilisé pour ce test est disponible sur http://ed.gomez.free.fr/vrac/xvidcore-mercurial.tar.bz2(...)
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.
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:
Thu Jun 3 21:13:20 2004
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.
Addendum: les scripts me permettant de déduire l'âge moyen d'une ligne de code.
# Annoter toutes les lignes.
$ (for i in `hg manifest |grep -E "\.(c|h|asm)$" | awk '{print $3 }'` ; do hg annotate $i |cut -d ':' -f 1 ; done ) > annotations.txt
# Chopper la date de chaque commit (j'ai patché mercurial/commands.py pour me donner un temps unix au lieu de time.asctime)
$ hg log | grep ^date: | awk 'BEGIN{i=0;} { printf("date[%3s] = %s;\n", i, $2); i++;}' |less > patches-date.dat
# Ecrire le script awk qui va faire le calcul
$ cat > losc-age.awk << EOF
BEGIN {
EOF
$ cat patches-date.dat >> losc-age.awk
$ cat >>losc-age.awk << EOF
for (i=0; i<444; i++) {
patch[i] = 0;
}
average = 0;
lines=0
}
{
patch[$1]++;
lines++;
}
END {
for (i=0; i<444; i++) {
average += patch[i]*date[i]/lines;
}
printf("%s\n", average);
}
EOF
# Et on trouve l'age moyen
$ awk -f losc-age.awk annotations.txt
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.
Biensûr tout ceci aurait pu être fait en Python, mais je ne connais pas Python :-)
Mon dépôt xvid converti utilisé pour ce test est disponible sur http://ed.gomez.free.fr/vrac/xvidcore-mercurial.tar.bz2(...)
> Lire le journal (23 commentaires, moyenne: 3,8).
Vous avez demandé le commentaire #603145.
Run by 
Cette page a été générée par Templeet en 0.0577s (dont 0.0054 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
questions
De ton temps y'avait combien d'autres contributeurs ?
Le projet est peut-être mature et n'a pas trop besoin d'évoluer ?
Y'a peut-être des alternatives beaucoup plus populaires qui attirent les contributeurs ?
[^]Re: questions
> De ton temps y'avait combien d'autres contributeurs ?
Le probleme c'est que "mon temps" s'etale sur les 3 dernieres annees, donc j'ai vu passer des gens ponctuels, j'ai intégré celui qui a fini par devenir le plus gros contributeur (en terme de fonctionnalités).
Le probleme du comptage, c'est que t'as les membres fondateurs endormis qui ont jamais dit: je reprens ou j'abandonne. Du coup ils sont peut etre 4, peut etre 0. Au moins 1 semble reagir sporadiquement aux contributions (skal).
Sinon pour repondre a ta question, dans les moments les plus fastes on a été 6 codeurs simultannés. Une moyenne de 2 actifs est plus realiste sur l'ensemble 2001-2005, plus en general toujours quelqu'un pour bosser plus ponctuellement sur un port ou des correctifs.
>Le projet est peut-être mature et n'a pas trop besoin d'évoluer ?
Mature oui dans la mesure où les utilisateurs l'utilisent même face à DivX qui est une machine commerciale qui s'impose par le nom plutot que par les fonctionnalites intrinseques du codec.
Par contre il peut encore largement evoluer. Le code est generalement assez pauvrement correlé. Je veux dire que les APIs internes ont été peu travaillées car elles sont été dictées par les besoins du moment. Et ca s'en ressent. Donc y a du travail du fond (fonctionnalites pouvant etre rajoutées) et du travail de forme (meilleur code).
>Y'a peut-être des alternatives beaucoup plus populaires qui attirent les contributeurs ?
DivX qui a la puissance commerciale, et une palanquée d'outil pour mr tout le monde afin de convertir en "un clic" ses videos.
Sinon dans le monde du libre, y a FFMPEG qui integre un codeur ISO MPEG4. Mais il est un chouilla moins bon qu'XviD car FFMPEG axe beaucoup son travail sur la partie decodeur. La partie codage n'est pas la plus active d'FFMPEG.
Et pour l'avenir, y a juste a dire que ISO MPEG4 Part 2 (Norme sous jacente a XviD, DivX4/5/6, FFMPEG MPEG4 etc...) est vieille de presque 5ans, et que y a h264 qui est archement plus sexy et mieux adopté par les professionnels du hardware (futur DVD-HD)
Donc pour conclure, sous des OS libres où DivX est pas dispo, t'as deux choix: xvid ou ffmpeg. Donc c'est pas non plus la fragmentation d'efforts entre projet qui explique la non evolution d'xvid.
Moi je pencherai plus à une désertion par niveau d'entrée trop élevé. Le codage vidéo c'est pas facile, y a plein de maths derrière et ca en rebute surement plus d'un.
[^]Re: questions
Je vais te donner mon opinion, ça vaut ce que ça vaut.
Admettons que je sois passionné d'encodage vidéo (c'est très vrai), que j'aie les capacités mathématiques nécessaires (c'est un peu moins vrai) et le temps pour m'embarquer dans un tel projet (c'est pas du tout vrai), je ne contribuerais pas à Xvid.
Pourquoi ?
Parce que xvid, selon la propagande libriste que j'ai entendue, repose sur la norme MPEG4 qui est brevetée.
Je préferais donc bosser sur Theora pour l'aspect purement vidéo.
Et, au niveau fonctionnalité comme chapitres, sous-titres, etc, je pense que ce n'est pas le rôle du codec mais bien du container.
Je contribuerais donc au projet Matroska (ce que j'ai été sur le point de faire d'ailleurs).
J'apprécie énormément le travail que tu as fourni, qui a, à mes yeux, contribuer au développement de Linux sur le desktop. (pouvoir lire et encoder des divx, ou apparenté, sans problème) Mais pour moi il est temps de promouvoir des alternatives complètement libres, qui peuvent être redistribuées et installées par défaut sur n'importe quelle machine. Je ne disais pas ça il y a deux ans, mais Theora a fait de réels progrès.
Et je suis sûr que Theora a pleins de défauts face à Xvid, mais malheureusement l'histoire nous a appris que la qualité technique n'est pas un critêre dans la réussite commerciale/populaire d'un produit.
[^]Re: questions
Theora bof bof.
A l'heure on beaucoup dise que les fondements du mpeg4 simple profile comme XviD sont dépassé, bosser sur Theora, basé sur VP3, je ne suis pas sur que ce soit spécialement motivant.
De plus bosser sur Theora c'est comme bossé sur vorbis, c'est étremant découragent et un grand moment de solitude. Les projets de la Xiph fondation sont on ne peut plus opaque, d'ailleurs on en a plus de nouvelles mit a par quelques developpement mineurs de vorbis réalisé par des membres extérieurs a l'équipe de dev, bizarrement depuis qu'ils ont liberé Tremor ( le decodeur vorbis en fixe ).
Il y avait bien Tarkin, mais bon cela fait longtemps qu'il s'est fait explosé par Snow dans le domaine du wavelet.
Donc bossé sur un codec as been avent même d'étre sortit pour une fondation muette, je ne suis pas sur que cela crée des vocations.
Maintenant comme tu le fais remarqué le match risque de se jouer ailleurs que sur les codecs video pure, mais sur les fonctions annexes.
Il relève de la responsabilité du lecteur de contrôler, par tous moyens, l'adéquation du message à ses besoins et de s'assurer qu'il ne causera pas de dommages aux personnes et aux biens.
[^]Re: questions
mouai theora completement libre de brevet, faudra me convaincre sachant que la simple operation de moyenne de pixel est brevete...
D'ailleur http://svn.xiph.org/experimental/derf/theora-exp/doc/patents.txt(...) ...
Apres si on les considere tous invalide c'est facile.
Ensuite c'est tres con de dire qu'un codec est brevete : on brevet des recettes et tu peux tres bien arrive au meme resultat (au sens de la validite au spec du codec, pas en perf) en utilisant 2 recettes differentes.
Enfin comme dit au dessus, la com de xiph c'est pas la joie...
[^]Re: questions
>Parce que xvid, selon la propagande libriste que j'ai entendue, repose sur la norme MPEG4 qui est brevetée.
Déjà, je dirais une première chose. Etant français, les brevets logiciels sur le MPEG4, je n'en ai rien à faire. Et je pense que pas mal de linuxfr'iens aussi (désolé pour les francophones du Canada et d'autres pays qui ont adopté de lois sur la propriété intellectuelle proches de celles des USA)
Puis en deuxième lieu, je te signales qu'en vidéo, plein de principes de base sont brevetés. A tel point que personnellement je juge tout simplement impossible de coder une image en la prédisant grâce à des références vers une image passée sans violer au moins un brevet déposé dans au moins un pays dans le monde. Des exemples, y'en a plein, prédire un vecteur de mouvement en prenant le vecteur median de ces voisins est breveté, prédire la valeur d'un pixel en utilisant une loi affine est breveté. IBM a déposé des brevets sur des techniques employées par XviD après que nous les ayons publiées (je pense au mode VHQ).
Theora ou XviD doivent violer des brevets l'un comme l'autre. Sauf que dans un cas, on tente pas de faire croire le contraire.
Donc à moins que tu te décides à ne pas contribuer à un seul projet de codec libre, alors acceptes de violer inconciemment des brevets dans dans plusieurs pays. C'est triste mais c'est comme ca.
[^]Re: questions
Zut j'ai oublié la conclusion: soit pragmatique.
[^]Re: questions
N'étant pas spécialiste du domaine, je veux bien te croire. Mais ma question est donc : pourquoi alors Fluendo prend la peine de contribuer et d'utiliser Theora, disant ne pas pouvoir prendre le risque d'utiliser Xvid ?
J'avoue ne pas avoir de sources sous la main, mais j'ai retenu (et peut-être déformé) cette conclusion là.
J'aimerais ton avis là dessus.
[^]Re: questions
disons que les 2 codecs violent des brevets, mais dans le cas de Theora, ils appartiennent (appartenaient ?) a On2Tech, qui les a "cédés" au monde libre, donc si tu t'en sers, On2Tech ne viendra pas te faire chier.
Dans le cas Xvid, c'est un ISO MPEG4 gnagnagna, les brevets appartiennent à un consortium d'entreprises que l'on connait bien, et qui n'hesiterons pas à venir t'embeter vu que c'est leur sport favori (bon ok, j'exagère ;)
[^]Re: questions
>N'étant pas spécialiste du domaine, je veux bien te croire. Mais ma question est donc : pourquoi alors Fluendo prend la peine de contribuer et d'utiliser Theora, disant ne pas pouvoir prendre le risque d'utiliser Xvid ?
Comme ca a été dit avant, XviD etant une implementation d'MPEG4, on doit bien violer quelques brevets au passage de façon certaine. Or derriere toute norme MPEG, un consortium d'ayant droit gere les droits liees a l'exploitation des normes de facon centralisée: le MPEG-LA http://www.mpegla.com/index1.cfm(...)
Dans le cas de Theora, tu as une boite On2, qui a promis a Xiph que son portefeuille de brevets relatifs à VP3 (base de theora) ne sera jamais exploité. Mais rien ne dit que On2 couvre avec ses brevets "gentils" l'ensemble des techniques mathematiques employees dans VP3/Theora.
Donc d'un coté, tu as une techno dont tu sais que:
- elle est minée par des brevets
- ces brevets sont gérés de facon centralisée par un consortium qui redistribue les royalties aux ayant droit.
De l'autre coté, tu as une techno dont tu sais que:
- Elle contient des procedes brevetes, dont certains ne posent pas probleme car on sait qu'ils ne seront jamais exploité par On2, et "surement" d'autres brevets dont on ne sait rien.
- On2 gere ses brevets, pour les autres brevets... c'est le néant, c'est à chaque entreprise détentrice de faire valoir ses droits.
Donc entre une techno clairement hostile (brevets connus+gestion centralisée et hyper organisée de leur exploitation) et une techno un poil friendly (majeur partie des brevets connus et innofensifs)... bah tu choisis de supporter la seconde, c'est clairement moins risqué et en plus c'est clairement plus en adéquation avec les licenses utilisées dans les projets formant la base de fluendo (gstreamer entre autres).
Ils ont su rester pragmatique et realiste. Ils ne pouvaient se mettre en cas d'infraction délibérée puisqu'il s'agit d'une entreprise légalement déclarée en Espagne il me semble.