Edouard Gomez a écrit 450 commentaires

Bon on a pas pu resister a faire une bonne grosse blagounette pour ce 1er Avril. Les quelques courageux qui ont sautés sur cette vraie fausse version, ont donc eu droit à une surprise ;-)

Cette version compressait toujours la meme séquence vidéo contenant un texte défilant qui disait "XviD April 1st Fool Edition -- Gotcha ;-)" (pour ceux qui ne connaissent pas la langue anglaise, cela veut grossierement dire "XviD, Edition Poisson d'Avril -- on t'as eu ;-)").

Pour que les décus de cette fausse sortie reprenne du poil de la bete, j'ai reposté la news, en indiquant que des bugs ennuyants ont pu être decouvert grâce à d'excellents retours utilisateur sur la version "Ni Hao", et que les correctifs devront subir votre torture dans une RC4 à paraître ce week end. On espère que cette version candidate soit la dernière et que la "vraie de vraie" 1.0.0 soit enfin offerte en pâture à vous, notre public adoré, dans la semaine qui suivra.

Hmmm tu nous sers le meme journal que la semaine dernière, j'aimes pas le réchauché ;-)

>Ceci dit, Édouard a dû participer au dépouillement des votes de son bureau de vote, pas de son canton entier. ;-)

Vivi, je ne suis pas encore omniscient, je me limite donc à mon seul bureau de vote :-)

Le depouillement etait divisé en 2 "équipes" de 3 tables de comptage, l'une pour les cantonales, l'autre pour les regionales.

La semaine prochaine, j'upgrade ma citoyeneté en version "Depouillement d'election regionale".

Ca donne ca:
http://article.gmane.org/gmane.comp.video.mplayer.devel/16000(...)

Je sais pas pourquoi, mais ca me laisse sur ma faim, j'ai l'impression (peut etre fausse), que KiSS a fait un don pour qu'ils ferment leur gueule

Cet avis reflete une impression du moment, car j'arrive pas bien a suivre l'enfilade puisqu'ils se refusent a publier les mails au complet et on obtient uniquement des bribes via les gars de chez mplayer.

Le programme lui meme etant une liste :-)

Je te conseille de faire une boucle while pour t'assurer que le sleep ne sort pas avant le temps souhaité (sur reception de signaux ou que sais je):

int sleeping_time = 600;
while ((sleeping_time = sleep(sleeping_time)));

Plus de détails dans la manpage "man 3 sleep"

Peut etre est il aussi utile pour toi de voir du coté de errno pour ne boucler que dans certains cas (type EINTR)

42

h264 a pour l'instant de bien meilleures chances pour les raisons suivantes:
- comme les MPEG1/2/4 c'est un consortium d'industriels qui le definissent (JVC ayant fait le plus gros).
- le matériel nécessaire pour decompresser du h264 est plus simple que leur equivalent mpeg4 pour une definition donnée.

Bref le premier point est preferable dans un secteur qui tente de définir un standard pour grand public. Le deuxieme point interessera les implementeurs hardware qui cherchent toujours a reduire les coups de prod.

Bon enfin ceci dit, on a peu d'info sur WMV9, donc peut etre que MS a implementé le meme type d'idees novatrices que h264 (blocks a taille variable, boucle de filtrage ds le codeur, codage entropique CABAC) en sortie au lieu d'un dictionnaire fixe... et de plus dans le domaine de la vidéo, c'est rarement le meilleur choix technique qui l'emporte (voir la VHS vs son concurrent de l'epoque, PAL vs SECAM vs NTSC standards remplis de compromis afin de rester compatibles avec les televiseurs noir et blanc de votre arriere grand mere...)

Toutes nos RC sont nommees "Bonjour", qu'on decline en toutes les langues qui sonnent bien. Y a eu:

- Aloha (tahitien iirc)
- Ciao (italien)
- Selam (Arabe)
- Niltze (azteque)
- Jambo (swahili)
- Ni Hao (Mandarin format pinin (phonetique))

Cette methode de nommage nous aurait permis une bonne floppée de pre releases avant de tomber a court de nouveaux noms :-) Au final y'a pas tant de pre releases, et tant mieux ;-)

Pour le module xvid4 adapté aux releases publiques de la série 1.0.x(-rcX), tu peux utiliser le programme GTK2 xvid4conf:
http://zebra.fh-weingarten.de/~transcode/xvid4conf/(...)

Ca te permet de charger/modifier/sauvegarder les fichiers de config. L'aide pour chaque option est dispo sous forme de popup... bref ca devrait t'aider.

Il faudrait plus d'informations. Sinon je vois ien deux solutions.

1 - tu as acces aux sources et tu peux donc y mettre des appels qui vont bien pour que d'une part ta demo graphique affiche des images dont les delta de temps sont constants (eg: 25fps) et d'autre part tu envoie ton buffer de rendu vers une librairie de ton choix telle que XviD ou FFMPEG.

J'avais fais ca pour la demo VIP2 releasé sur linux, vois un de mes anciens journaux.

2 - tu n'as pas acces au code. La ca devient plus complique puisque tu ne peux t'assurer ni du framerate constant ni de la capture de l'ecran. Mais bibi a une solution au moins a la deuxieme partie du probleme. En fait il faut que tu crees une librairie en remplacement de ton GLX/WGL. Tu y definis le symbole glXSwapBuffer(), et biensur tu t'arranges pour que ta fonction de remplacement fasse appel a glReadPixels() et envoie le buffer a un codec, puis fasse un appel au vrai glXSwapBuffer.

Documentes toi aussi du coté des weaks symbols dans ld.so. Il me semble que tu peux "casser" la liaison d'un symbole weak et la remplacer par tes propres symboles.

Bon c'est pas une solution clef en main, mais je te donne de bonnes pistes d'investigation.

Pour faire cours car ca a été rabaché des milliards de fois a peu pres pour chaque news sur des gestionnaires de version: le coté distribué. Bon y'a d'autres raisons, mais celle la est la #1.

>à quand le prochain ?!

Ca se fera un jeudi !

Oui je sais -->[]

Mauvaise analyse. La stupidité n'engendre pas les autres maux.

Le seul facteur commun a toutes ces choses, c'est l'homme. Triste a avouer mais c'est comme ca.

Half life 2 ne joue pas dans la meme catégorie. D'ailleurs, Duke Nukem Forever etait deja attendu a l'epoque de Half Life 1, c'est pour dire si DNF est le sumum du vaporware ;-)

>Mais ils ne savent pas faire ce que nous faisons.

C'est vrai qu'ils etaient les experts en vaporware, personne ne les a jamais depassé. A 4kB/s tu avais un film qualité VHS sur 10 disquettes 1.4MB, ou encore 46 films sur un simple CDR 650MB de l'epoque... D'ailleurs le son auraient pris plus de place que la video (a l'epoque le MP3 regnait seul, et en dessous de 128kbps le resultat etait pas fameux), ce qui en soit est LE signe majeur qu'i2bp se foutait de la gueule de tout le monde, car tout le monde sait que le son est une information autrement plus "simple" que l'image.

Bon dans la catégorie "vaporware ultime, mention 'je persiste et je signe'", je nomme 3drealms pour Duke Nukem Forever... que certains attendent depuis, oulaaaa, 5 ou 6 ans si je ne me montres pas. Ce jeu a eu le temps de passer du moteur de quake1 a celui d'unreal puis passage par le moteur de quake2, et pis rebelotte avec le moteur d'unreal tournament... j'en suis meme perdu avec tant de chgts (qui sont difficilement justifiables tant du point de vue technique que commercial)...

>Je pensais que la signature garantissait le fait que le message soit bien de l'auteur.

Relis bien ma phrase, j'emploie le terme chiffré et non signé :-) Un message chiffré vers monsieur B en partant de monsieur A se fait grace a la clef publique de monsieur B. Monsieur B ayant la partie privée de la clef, il pourra decoder le message qui lui est envoyé.

Donc pour peu que monsieur B ait publié sa clef publique sur un keyserver, le spammeur peut verifier si le keyserver contient une clef pour son adresse destinataire et a fortiori s'en servir pour t'envoyer un spam chiffré.

>après tout c'est fait pour ça

Je parlais du role des clefs publiques dispo sur les keyservers qui sont utilisées pour chiffrer le message en fonction de son destinataire.

>c'est compliqué de signer un email avec une clé ? (GnuPGP etc...) Par exemple avec Mozilla ?

Non c'est tres simple avec l'extension Enigmail: http://enigmail.mozdev.org/(...)

Mais la lecture d'une documentation GPG t'aidera à comprendre ce que tu fais, car enigmail ne fait au final que te donner un moyen supplémentaire de te servir de gnupg, en aucun cas il t'explique ce que le chiffrement ou les signatures te garantissent.

>Si tout le monde utiliserais les signatures, ca ne simplifirais pas le problème du tri de ce qui est spam et non spam ?

Oui et non, cad que pgp/gpg te permettent de garantir la confidentialité du message ou son authenticité. Un spammeur peut tres bien decider d'interroger un keyserver pour t'envoyer un spam chiffré grace à ta clef publique (après tout c'est fait pour ça), ou utiliser sa propre clef (probablement crée pour l'occasion) pour te garantir que le SPAM qu'il t'a envoyé est authentique (des fois qu'un spam authentique soit une moindre nuisance...).

Oui le changelog est généré automatiquement dans Arch (pour peu que tu le veuilles). Pour un exemple (un poil traficoté a coup de sed pour eviter le spam en laissant mon email trainer 50x ds le log) voir:
http://ed.gomez.free.fr/projects/xvid-devapi4/ChangeLog-devapi4.txt(...)

Bon il faut savoir que je maintiens cette branche dans une archive Arch tout seul, donc je suis obligé de dire "From truc" pour tracer un peu a qui on doit tel ou tel patch. Mais si les autres dev utilisaient arch , le "qui a fait quoi" serait géré automatiquement, et ferait parti de l'historique. Voir un mail assez recent sur xvid-devel:
http://article.gmane.org/gmane.comp.video.xvid.devel/3757(...)

Trois branches, la mienne ne servant qu'a l'integration du travail des 2 dev PPC.

NB: les logs automatiques sont generes par "branche".

Non pas du tout, apres 6mois de recherche d'emploi en R&D (au sens large), j'ai opté pour l'option alimentaire garantie: ... la societe de service infomatique. Le poste exact s'apelle: ingénieur d'etude.

A mon avis, je verrai pas tant de logiciels libres ici. sniff

Juste une petite correction... pour l'exactitude.

Le programme ne tente pas d'acceder a un symbole GLIBC_2.0. En fait il tente d'acceder au symbole errno (la variable qui contient le numero de la derniere erreur générée) version GLIBC_2.0.

En effet, les librairies ELF permettent de définir des symboles versionnés. C'est à dire qu'on peut avoir une fonction foo() version VERSION1 et une autre VERSION2, les deux différents par leur ABI. Le linker fait sa petite affaire ensuite au moment de la relocation de l'executable+libs. C'est une feature qui meme si je la connais me reste totalement inconue dans la pratique et je ne connais guere que la glibc qui l'utilise.

Dans la glibc, les versions permettent par exemple de distinguer errno sous forme de variable (pas thread safe) de errno() qui retourne le code d'erreur correctement pour chaque thread. Les détails je les connais pas mais cette ruse de sioux fonctionne :-)

Par contre j'ai aucune solution propre sauf l'installation de la libc correspondante qq part (disons ${vieille_libc}) et de lancer le programme avec:
LD_PRELOAD=${vieille_libc}/libc.so.5(<-- version de la glibc 2.0 iirc) maple

Mais je garantis pas le resultat du tout, d'autres libs chargées par maple pouvant peut etre avoir besoin, elles, d'une glibc plus recente.

Bilan de la journée:
884 copies recues... on peut noter une legere amelioration.

Je rappelle aux plus jeunes d'entre nous que ce réseau IRC s'appelait autrefois OpenProjects.net... sniff avec le temps tout s'en va :-)

Déjà ? debian c'etait mieux à vent quand les logiciels etaient vieux^Wstables.

$ apt-get install door
$ mv /dev/me "/dev/-->[]"

Non pas que le script en soi ne m'interesse pas pour le driver, mais hotplug est affaire de distro, chacune y fait sa popotte alors je sais pas trop, deja vu l'utilisation minoritaire de mon excellent (non j'ai pas la grosse tete ;-) ) script Init sysV... enfin voila.