David Madore's WebLog: Pourquoi les soucis informatiques en attirent-ils toujours d'autres ?

[Index of all entries / Index de toutes les entréesLatest entries / Dernières entréesXML (RSS 1.0) • Recent comments / Commentaires récents]

↓Entry #1592 [older| permalink|newer] / ↓Entrée #1592 [précédente| permalien|suivante] ↓

(dimanche)

Pourquoi les soucis informatiques en attirent-ils toujours d'autres ?

Ce dessin xkcd illustre très bien ma situation…

Avant de sortir une version propre de mon programme de calcul d'ensemble de Mandelbrot, je jetais un œil à la vidéo que j'ai faite (ainsi qu'une seconde, pas encore annoncée de façon très visible), et je me suis rendu compte qu'il y avait des artefacts désagréables — la vidéo saute un peu à certains moments, parce que des frames ont été sautées — la faute en étant apparemment à MEncoder que j'ai utilisé pour l'encoder et qui, apparemment, à des bugs dans le muxer. Solution : utiliser ffmpeg à la place. Ce qui implique de convertir les options barbares de MEncoder (du style mencoder -mf fps=25 'mf:///data4/mandel2-video/interframes/*.png' -audiofile /tmp/audio3.wav -noskip -vf harddup -ovc x264 -x264encopts frameref=8:bframes=2:8x8dct:me=umh:subq=7:nodct_decimate:trellis=2:weight_b:direct_pred=auto:crf=20 -oac mp3lame -lameopts preset=standard -o mandelzoom.avi) en des options tout aussi barbares de ffmpeg (du style ffmpeg -r 25 -s 640x480 -aspect 4:3 -i ffmpeg-frame-links/%04d.png -i /tmp/audio3.wav -vcodec libx264 -refs 8 -bf 2 -flags2 dct8x8+wpred -me_method umh -subq 7 -trellis 2 -directpred 3 -crf 20 -acodec libmp3lame -aq 2 mandelzoom.avi) — heureusement, quelqu'un a eu la gentillesse de m'aider avec ça, mais vraiment, l'encodage vidéo, ça a un côté désagréable magie noire. Et après, évidemment, il me faudra modifier les torrents que j'ai mis en place vers cette vidéo, opération plutôt pénible, et demander aux gens qui les ensemencent de bien vouloir passer à la nouvelle version. Mais je n'en suis pas encore là !

Parce qu'il y a eu divers interludes amusants. D'abord un problème de réseau dans ma connexion entre mon PC chez mes parents (où je passe le dimanche) et celui de mon bureau (dont je n'avais besoin que de façon indirecte mais néanmoins importante) : encore un de ces satanés problèmes de MTU qui conduisent à des symptômes généralement mystérieux de connexions qui gèlent intempestivement, et je n'ai pas réussi à en comprendre la cause (la connexion à mon PC au bureau est compliquée parce que l'ENST a un pare-feu parano qu'on est censé traverser avec un PPTP, et quelque part entre Wanadoo et l'ENST les paquets PPTP se font fragmenter puis réassembler, puis jeter silencieusement parce qu'ils sont trop gros — je n'ai pas réussi à en savoir plus), mais ça m'a fait perdre beaucoup de temps.

Ensuite, un disque dur de mon ordinateur (toujours celui qui est chez mes parents à Orsay) a décidé de se mettre à agoniser. Pour dénoncer les coupables, c'était un Samsung, et il était tout neuf : je l'ai acheté pour remplacer un autre disque dur qui est aussi mort tout récemment. Et bêtement j'avais copié dessus des données sauvées depuis cet autre disque dur et que je n'avais pas encore disséminées ailleurs — pas des données très importantes, mais il faut croire qu'elles portent la poisse. Les choses vraiment importantes étaient de toute façon stockées de façon redondante (en RAID), mais comme souvent dans ces cas la perte n'est pas tant dans les données elles-mêmes que dans le temps qu'on passe à reconfigurer les choses et à sauver ce qui peut l'être (là, le disque agonisant est en train de cracher quelques secteurs — la plupart intacts — au rythme frénétique de huit et demi méga-octets par minute, à peu près le taux de transfert d'une disquette, ce qui signifie qu'il me faudra donc autour de deux semaines non-stop pour tout extraire). Enfin, si ma patience et le disque en question tiennent jusque là.

Après ces interludes, je suis revenu à mon encodage de vidéo avec ffmpeg, et j'ai constaté avec plaisir que celui-ci mourait dans d'atroces souffrances (segfault, abort, enfin peu importe) à la fin de l'encodage, apparemment à cause d'un buffer overrun dans l'encodage audio, bravo. En faisant traiter l'encodage audio par un autre programme, je m'en suis sorti. La vidéo résultante était quand même beaucoup plus grosse que celle produite par MEncoder à partir des mêmes images, avec le même codec, les mêmes options du codec, et à qualité censément égale : je ne sais pas pourquoi, et à ce stade-là je ne veux vraiment pas savoir.

J'écrirai une nouvelle entrée quand ces fichues vidéos seront correctement (ré)encodées.

↑Entry #1592 [older| permalink|newer] / ↑Entrée #1592 [précédente| permalien|suivante] ↑

[Index of all entries / Index de toutes les entréesLatest entries / Dernières entréesXML (RSS 1.0) • Recent comments / Commentaires récents]