Ubuntu-fr

Ah ouais, effectivement.

J'ai pas retouché à Rosalind (mais j'ai tout fait en Ruby). Je pourrais recommencer en Python
(bon, pas vraiment le temps malheureusement)

J'ignorais même que deux modèles cohabitaient.
Et oui, c'est typiquement le concept de classe abstraite que j'ai d'abord voulu reproduire mais je n'en avais finalement pas vraiment besoin et je trouvais que cela allourdissait le code pour un bénéfice inexistant dans mon cas.

Merci pour tes liens d'ailleurs.

Heu... oui effectivement...(bon, vu l'heure où j'ai posté...).
J'aurais plutôt du mettre un truc dans le genre:

a <- b <- 2

J'étais juste agréablement surpris que ça fonctionne en R (peut-être parce que R ne m'a quasiment jamais agréablement surpris jusqu'à présent...).
C'est par exemple impossible en Lua (au contraire de Ruby, Python ou même Matlab/Octave):

Lua 5.2.2  Copyright (C) 1994-2013 Lua.org, PUC-Rio
> a = b = 2
stdin:1: unexpected symbol near '='

Je suis sur le point de publier une lib en C qui permet de générer des fichiers AVI à partir d'un flux vidéo + audio. Il s'agit en fait d'un fork d'une librairie que j'utilise dans le cadre de mon projet de vidéo en embarqué (libkohn-avi).

J'ai besoin de vos conseils/éclaircissement sur ces points:

• J'ai déjà apporté pas mal de changements à la librairie (et d'autres sont à venir). Étant donné qu'elle est sous LGPL, je suis obligé de redistribuer mes changements et, en plus, sous la même licence ou la GPL. Vous confirmez? (Ça me saoule un peu car je préfère favoriser les licences plus "libres" quand à leur utilisation, surtout pour une librarie mais bon... je vais essayer de contacter l'auteur de la lib, sait-on jamais s'il accepte que je publie ma version sous une autre licence (BSD/MIT ou Apache).

• Il n'est pas précisé quelle version de la LGPL s'applique. Il y a seulement ce bout de texte en entête des fichiers sources:
  This code is copyright 2008-2011 by Michael Kohn
  This code falls under the LGPL license
  Du coup, quelle version de la LGPL dois-je utiliser? Forcément la dernière (donc la 3) ou bien je peux prendre la 2.1?

• Je ne suis pas trop sûr de quelle façon je suis censé répartir mes fichiers sources dans mon dépôt. Concrètement, j'ai pour le moment 6 fichiers sources (3 C et 3 header). Seul une paire de fichiers contient les fonctions qui sont censées être utilisées lorsque l'on utilise la lib dans un programme. Une paire contient des fonctions utilitaires générales et la dernière paires des fonctions utilitaire pour la création du fichier AVI.
  Je pensais à quelque chose dans le genre (avec éventuellement un dossier pour des tests):
  ├── LICENSE
  ├── Makefile
  ├── README.md
  ├── demo
  │   ├── demo.c
  │   └── demo.h
  ├── doc
  │   └── Doxyfile
  └── src
      ├── gwavi.c
      ├── gwavi.h
      └── utils
          ├── avi-utils.c
          ├── avi-utils.h
          ├── fileio.c
          └── fileio.h
  Avec génération de libgwavi.so à la racine du dossier. Ça vous parait correct?

Ah, une fois publiée, une revue de code sera toujours bienvenue, surtout pour une lib.

avi-utils.c contient des fonctions utiles pour... la création d'un fichier AVI, tel que création du header etc.
fileio.c contient des functions relatives aux... IO, telles que write_int, write_chars_bin, etc.

Sinon, merci pour les infos et le PDF, qui me sera bien utile je pense.
Faut encore que je me penche plus en détail sur le format pour améliorer la lib.

Non, ça n'est pas prévu et je ne pense pas que ça le sera.

J'ai déjà mis du H264 dans un AVI avec cette lib et ça marche sans problèmes (pour ce que je l'ai testé). En fait, l'application de vidéo en embarqué que j'écris génère un flux vidéo (720p et 1080p pour le moment) compressé en H264 et le met dans un fichier AVI via cette lib (il est possible de mettre le flux dans d'autres conteneurs aussi, évidemment).

C'est vrai que "utils" n'est peut-être pas pertinent. Le truc, c'est que le seul "header public" est gwavi.h.
Du coup, si je te suis bien, je devrais plutôt faire le layout suivant?

├── AUTHORS.md
├── LICENSE
├── Makefile
├── README.md
├── doc
│   └── Doxyfile
├── examples
│   ├── Makefile
│   ├── demo.c
│   └── demo.h
├── inc
│   └── gwavi.h
├── lib
└── src
    ├── avi-utils.c
    ├── avi-utils.h
    ├── fileio.c
    ├── fileio.h
    └── gwavi.c

Non, elle prévient rien du tout.

Comme tu dis, je pourrais mettre une note à ce propos, genre dans le readme. Enfin bon, dans un autre sens, ça veut dire qu'il faudrait que je liste tous les fourcc et que je dise en détail lesquels sont supportés et lesquels ne le sont pas. Je ne sais pas si j'ai vraiment envie de m'amuser à ça.

Bon, je finirais demain. Il ne me reste plus qu'à configurer doxygen et écrire une application de démo. Bon, l'application de démo attendra je pense. Je mettrais un disclaimer pour prévenir que la lib n'est pas encore en version finale.

Si un jour vous avez besoin de couper les N premières frames d'une vidéo RAW en YUV, pas la peine d'écrire un outil pour le faire, je viens d'en publier un: yuvcutter.

Oui, je suis au courant. Seulement, pour autant que je sache, le décodeur de référence H264 ne permet que le calcul du PSNR.
Ceci dit, ça pourrait être intéressant que je fasse aussi le calcul du SSIM. Mais bref, comme tu dis, dans tous les cas ce ne sont pas des métriques à prendre pour argent comptant, seulement un indicateur.
Donc évidemment, je ne tiens pas compte uniquement de ça. Il faut d'ailleurs aussi que je fasse des tests de random access. Le but de tout ça, c'est de jouer avec les paramètres de l'H264 pour trouver un bon compromis qualité/taille de fichier.

Peut-être. J'y jetterais un œil.

Tu bosses sur des projets video?

Un article que j'ai trouvé intéressant à propos du workflow des pull-requests sur Github.

Personnellement, je ne trouve pas ce système de pull-requests pratique. Si je veux contribuer à un projet qui utilise git (mais n'est pas sur Github), alors je procède ainsi:
- clone du dépôt
- création d'une branche locale
- modif souhaitées dans la branche locale, avec commit etc.
Une fois que j'ai fini mes modifs, je pull un dernier coup puis git format-patch et envoi du tout par e-mail. S'il y a un problème, je retravaille dans ma branche et refait la même chose.

Je trouve ce workflow très simple. Le fait de devoir forker, cloner le fork, pusher et faire une pull-requests à la façon Github, je trouve ça un peu pénible. Enfin, je ne m'y prend peut-être pas de la bonne façon...

Non, pas forcément. Un exemple d'application est la détection d'objets en approche par un avion. C'est aussi utile dans le civil.

C'est journée publication de code