mercredi 20 août
April | Agenda du libre | Framasoft | Léa-Linux | Lolix | JeSuisLibre | Eyrolles | LinuxMag | Veni, Vidi, Libri | InLibroVeritas | LinuxGraphic
Faire un don ! | | style | statistiques | contactez-nous | plan | lettre d'information
Accueil :: Dépêches :: Archives :: Proposer une dépêche :: Journaux :: Forums :: Entretiens :: Suivi :: RDF

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.


# 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 #603068.

Symptomatique

Posté par Beretta_Vexee () le 20/07/2005 à 15:45. (lien). Évalué à 6.

Je vais donner mon point de vue de personne relativement intéressé qui suit le projet depuis relativement longtemps ( projet mayo ) de l'extérieur.

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 ...

--
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.

  • [^]Et si le problème était autre part?

    Posté par Gluck_ (page perso, ) le 20/07/2005 à 20:49. (lien). Évalué à 3.

    Et si le problème était autre part?

    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.

    --
    wikignole

    • [^]Re: Et si le problème était autre part?

      Posté par Hank Lords (Jabber id, ) le 20/07/2005 à 21:33. (lien). Évalué à 1.

      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.


      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_ (page perso, ) le 20/07/2005 à 21:52. (lien). Évalué à 1.

        Certes c'est une solution mais je ne pense pas qu'elle soit viable à long terme. Ce n'est que la présence permanente d'un mainteneur qui permet la pérennité de ce genre de projets. Or, la faible disponibilité de gens ayant les compétences requises pour ce faire nous met devant un problème purement mathématique. Il n'y a pas en permanence quelqu'un ayant la motivation et les compétences pour ce faire de manière bénévole.

        Le soutien d'une entreprise est donc capital (ce qui ne veut pas dire faire du proprio)

        --
        wikignole

        • [^]Re: Et si le problème était autre part?

          Posté par Nicolas Boulay () le 20/07/2005 à 22:07. (lien). Évalué à 4.

          y'a aussi la barrière d'entré dans un gros projet. C'est toujours plus facile d'attaquer quand c'est encore petit.

          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 ?

          • [^]Re: Et si le problème était autre part?

            Posté par Matthieu C () le 21/07/2005 à 05:44. (lien). Évalué à 4.

            oui mais snow utilise d'autre fonction 'classique' d'autre fichiers : rangecoding, ...

            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 () le 21/07/2005 à 07:51. (lien). Évalué à 3.

              certe.

              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 :/

          [^]Re: Et si le problème était autre part?

          Posté par pascal massimino () le 30/07/2005 à 08:53. (lien). Évalué à 1.

          Bonjour,
          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

Run by Team LinuxFr.org

Cette page a été générée par Templeet en 0.0557s (dont 0.0069 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.