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(...)
# questions
Posté par patrick_g (site web personnel) . Évalué à 5.
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
Posté par Edouard Gomez (site web personnel) . Évalué à 9.
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
Posté par ploum (site web personnel, Mastodon) . Évalué à 7.
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.
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: questions
Posté par Beretta_Vexee . Évalué à 2.
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.
[^] # Re: questions
Posté par M . Évalué à 2.
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
Posté par Edouard Gomez (site web personnel) . Évalué à 7.
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
Posté par Edouard Gomez (site web personnel) . Évalué à 2.
[^] # Re: questions
Posté par ploum (site web personnel, Mastodon) . Évalué à 2.
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.
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: questions
Posté par billbaroud . Évalué à 1.
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
Posté par Edouard Gomez (site web personnel) . Évalué à 2.
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.
# C'est ce que tu craignais
Posté par Gart Algar . Évalué à 3.
# les jeunots sont des feignasses, c'est bien connu (no joke)
Posté par yojik77 . Évalué à 7.
Il y a peut-être un anti-effet de Stockholm aussi, avec le recul, on mesure les heures et semaines consacréss (gâchées ?) qui ne reviendront plus et on s'estime toujours un peu floué.
Un plus vieux con que moi encore me dit aussi que la bataille des enjeux collectifs est perdu, et qu'un danger public que sarko a un boulevard devant lui, l'individualisme n'est plus seulement "contemporain", il est généralisé et enraciné dans les consciences.
Pour moi, la solution a été radicale : je me suis éloigné significativement demon ancienne structure pour ne pas 1°) me causer du chagrin bétement 2°) être tenté d'invectiver mes successeurs qui faisaient ce qu'ils pouvaient/voulaient. Par contre, je ne suis toujours pas passé à autre chose, un rien d'appréhension peut-être...
Bref, je n'ai pas de commentaire à faire sur la mêthode d'évaluation mais je voulais te communiquer mes sentiments sur ce sujet. Mixed feelings, indeed.
Ceci étant dit, méga clap-clap-clap àtoi sur la qualité de Xvid !! C'est un codec brillant et je pense m'en servir abondamment prochaîenement pour les videos de mon mariage (dv --> avi//Xvid).
bref, merci pour tout Edouard !!
Fraternellement,
Yoj'
[^] # Re: les jeunots sont des feignasses, c'est bien connu (no joke)
Posté par skeespin (site web personnel) . Évalué à 1.
je pense qu'il est plus facile de repartir de 0 que de continuer un travail sans avoir intégré le contexte.
Je ne sais pas comment ca s'est passé avec toi Edouard mais si tu veux que ton projet continu a vivre, il faut que tu trouves surtout une personne hyper motivée pour apprendre et pas forcement un dieu du code car coder ca s'apprend. Une personne peu suffir pour fédérer un ensemble de compétence autour d'un projet.
[^] # Re: les jeunots sont des feignasses, c'est bien connu (no joke)
Posté par Edouard Gomez (site web personnel) . Évalué à 7.
Bah on a un chan IRC #xvid@freenode.org qui se voulait orienté developpeur. Au final, la notoriété d'XviD faisant son chemin, le chan s'est plutot orienté "utilisateur fan de la premiere heure". Donc de ce coté là, j'ai pas pu en tirer grand chose. Ensuite dans la communauté Doom9.org, y'a un tas de fanatiques lunatiques (je suis un peu méchant, mais je trouve que ces geeks butinent un peu tous les codecs, et n'hesitent pas à changer au lieu de fournir des efforts pour améliorer leur préféré du moment) qui s'extasient sur XviD mais qui dès qu'il s'agit de contribuer, hop deviennent invisibles. Donc parmi les gens plutôt môtivés auquels j'avais accès, personne n'était apte a reprendre.
Apres plus de 6mois où je disais a qui le voulait que j'allais partir, j'ai commencé à prévenir les gens qui m'envoyaient des patchs regulierement: "je vais arréter de maintenir XviD, merci de commencer a forwarder systèmatiquement sur xvid-devel pour que quelqu'un prenne en charge le patch". Puis biensur, appel aux autres dev de la xvid-team pour qu'une reprise du flambeau s'opère...
Au vu des maigres résultats, j'ai fais ma derniere release pour ne pas partir comme un sauvageon en laissant un CVS dans un état inconnu. Je pouvais pas faire beaucoup mieux.
# Symptomatique
Posté par Beretta_Vexee . Évalué à 6.
Je crois que le problème ne touche pas que XviD, tous le domaine du développement de codec video et même audio, est dans une mauvaise passe. Il y a quelques mois/années, il n'y avait pas un jour sans que Doom9 n'annonce un nouveau projet, un nouveau soft et je ne parle même pas de ses forums. Depuis quelques mois, on doit se contenter de quelques mises a jours mineurs, des projets interessnt comme snow, les conteneurs et codec nouvelles générations ou expérimentaux, débordez d'activités.
Je crois même si ce n'est sûrement pas le déclencheur mais plus un symptôme, l'emboche ou le débochage de pas mal de développeur de codec par des gros boites commes nero a donné de grand coup de frein, a un domaine qui se ralentissé déjà quelque peut de par la maturité de certaines solutions. Hors avec la maturation arrive le travail chiant de tunning, de documentation, etc etc ... qui passionne beaucoup moins les foules de coder le nouveau système de compression révolutionnaire.
D'un certain coté le problème a déjà et est toujours vécue par les développeurs de codec audio, une explosion de l'activité, Musepack, Vorbis, monkeyaudio, flac, speex, etc etc ... puis plus rien. Les derniers news sur hydrogenaudio ne concerne plus que des mises a jours de foobar.
C'est d'autant plus dommage, car comme tu le fait remarqué il reste encore beaucoup de chose a faire suffit de voir l'orientation prise par DivX, ou ratDVD, support des soustitre en natifs, menus DVD, multi-angle etc etc ...
[^] # Et si le problème était autre part?
Posté par Gluck_ (site web personnel) . Évalué à 3.
Nous sommes en présence d'une concurrence entre deux modèles. D'une part, le développement d'une solution libre qui n'a malheureusement pas de support financier et qui ne repose donc que sur du bénévolat et d'autre part, une solution propriétaire qui repose donc sur de l'argent et donc des codeurs payés (vous me pardonnerez surement de réduire le problème au seuls xvid/divx)
Bénévole de longue date à plus ou moins tous les échelons dans une ASBL (association loi 1901 en Belgique) j'ai eu l'occasion à plusieurs reprises d'être désabusé sur le temps dépensé, j'ai du passer le flambeau... Cependant, je ne pense pas que le problème principal vienne de la. A mon avis, il repose sur la différence des modèles.
En effet, nous sommes dans un domaine ou le niveau mathématique requis est élevé si on veut comprendre ce que l'on fait et ou l'on va. Or, je ne connais que peu (pas en fait) de geeks qui veulent bien faire quelque chose sans le comprendre. Cela restreint donc l'accès à ce genre de projets. Et c'est la à mon avis que cela coince. Le libre est basé sur la possibilité au plus grand nombre de faire avancer le projet, que ce soit en programmant, en traduisant ou en documentant (ou autre). Et ici, nous nous retrouvons dans un cas de figure ou seuls les matheux peuvent le faire.
Je vois déjà revenir tout ceux qui me diront que pourtant, le libre a réussi à coder Linux et d'autres choses au moins aussi géniales mais le niveau était-il aussi élevé pour rentrer dans la danse? N'est-ce pas un domaine bien mieux documenté? Les connaissances moyennes dans ce genre de domaines ne sont-elles pas plus élevées? De plus, nous avons maintenant beaucoup de développeurs payés pour ce faire, ce qui permet de se payer de la qualité (ce qui ne sous-entend en aucune manière que bénévole veut dire mauvaise qualité).
Bref, je pense que pour garder un haut niveau, Xvid devra d'une manière ou d'une autre se trouver un soutien financier qui lui permettra de continuer a être développé de manière soutenue, sous peine d'être dépassé par les alternatives proprio.
[^] # Re: Et si le problème était autre part?
Posté par Hank Lords . Évalué à 1.
Ou trouver un autre passionné pret à perdre des heures de temps libre pour reprendre le flambeau de l'auteur du journal.
[^] # Re: Et si le problème était autre part?
Posté par Gluck_ (site web personnel) . Évalué à 1.
Le soutien d'une entreprise est donc capital (ce qui ne veut pas dire faire du proprio)
[^] # Re: Et si le problème était autre part?
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
Si le projet est bien balisé et délimité, tu permets qu'un mec ayant un gros bagage mathématique puisse passé un peu de temps sur xvid.
D'ailleurs, par curiosité, j'ai matté snow de ffmpeg, la seul doc que j'ai trouvé, c'est le fichier snow.c du projet ffmpeg de 4000 lignes.
donc snow, le nouveau codec, tient sur 4000 lignes. combien pour xvid ?
"La première sécurité est la liberté"
[^] # Re: Et si le problème était autre part?
Posté par M . Évalué à 4.
Donc si le projet comportait que snow il ferait becoup plus que ce simple fichier...
[^] # Re: Et si le problème était autre part?
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Ce que je voulais dire est que le projet ffmpeg fournis suffisement de doc et de fonctionnalité générique pour qu'un mateux puisse faire joujou avec un nouveau codec.
D'ailleurs, snow utilise la TO comme transformation, mais il ne parle pas du codeur :/
"La première sécurité est la liberté"
[^] # Re: Et si le problème était autre part?
Posté par pascal massimino . Évalué à 1.
Unefois n'est pas coutume, je vais ramener ma fraise:
Merci Gluck_, pour la pertinence de ton message. Je pense
que tu as bien cerne' le probleme, et ca tranche avec la tendance
ambiante "youki les p'tits zoizos". Je peux meme le traduire
en chiffres: on me donne 50000balles par mois pour ecrire
du codec. Libre ou pas, la competence n'a pas a etre gratuite.
just my 0.02e
-Skal
# des statistiques et du reste ...
Posté par Mouns (site web personnel) . Évalué à 7.
Mais, bon, on parle de l'age moyen ... mais que représente une moyenne arithmetique ?
Juste une distribution équiprobable des valeurs ( connu aussi sous le nom d'esperance ). cela veut dire qu'une moyenne est sensible aux valeurs et non aux quantités ( de valeurs ).
Dans ton cas tu travailles avec une moyenne arithmetique, et une moyenne arithmetique est tres sensible aux grandes differences de valeurs ( normal puisqu'il travaille sur les valeurs ).
Un exemple con :
Tu as 999 personnes qui gagnent 1000¤ et 1 personne qui gagne 1000 000¤, la moyenne arithmetique est de 1999¤ par personne.
Par contre, si la seule personne ne gagnait que 100 000¤. la moyenne serait de 1099¤.
Dans le cadre d'une distribution de quantité de valeurs, travailler sur les medians et quartiles ( voire deciles ou centiles ) a plus de sens.
Dans notre exemple, la mediane serait exatement à 1000¤ et meme le dernier centile serait à 1000¤ par contre, seul changerait la borne sup de l'échantillon.
Dans le cadre de l'etude de l'age, il serait interessant d'etudier la difference de distributions des quantités d'ages de lignes ( genre 10 lignes de 5j, 50 de 6 mois, ... ).
Si cela se trouve, tu verras peut etre qu'une ligne sur deux à moins de 3 mois ... une ligne sur quatre plus de 2 ans ( quantités totalement dites au hasard ).
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.