Re: [pymecavideo] Branche 5.4 committed

[Georges Khaznadar <georges.khaznadar@xxxxxxx>]

Bonjour Cédric,

Cédrick FAURY a écrit :
> J'ai envoyé un rapport de bug ce matin, vous l'avez eu ?

pas vu passer.

> J'y indiquait que je n'arrivais pas à ouvrir la vidéo
> Effet_force_magnetique.avi car pymecavideo lui détecte un framecount
> de zéro...

Je fais le pari qu'OpenCV est maintenu par suffisamment de gens sérieux
et motivés pour que ses défauts de jeunesse soient corrigés peu à peu.
Bon, je dois reconnaître qu'il m'est déjà arrivé de perdre des paris de
ce genre. Cependant il semble qu'Intel a lâché le code d'OpenCV dans la
nature pour que ça fasse acheter plus de processeurs rapides, peut-être
que cette entreprise tient aussi à ce que ce logiciel ne refroidisse pas
complètement.

Au cas où nous serions gênés trop souvent, nous pourrions passer un peu
de temps à échager du courreil avec les développeurs d'OpenCV pour leur
demander quels sont les formats (conteneurs, codecs) qu'ils utilisent de
préférence ... à mon avis, ça doit quand même marcher, chez eux.

> J'ai été pas mal occupé ces derniers temps et j'ai suivi d'assez
> loin vos travaux sur OpenCV.
> Puis-je avoir un petit résumé de ce qui se passe à l'ouverture d'une video ?

Rien d'extraordinaire, sinon qu'au lieu d'utiliser Ffmpeg on utilise
OpenCV qui fait plus vite. C'est surtout pour la vidéo recalculée que
c'est nettement supérieur : OpenCV permet de recadrer la vidéo d'origine
à la volée, sans avoir à générer de fichier vidéo tampon.

> Par exemple, je ne comprends pas pourquoi vous lancez testfilm.py
> par une commande externe ...

OpenCV ne traite pas correctement toutes les vidéos, du moins sous
Linux. Donc avant de l'utiliser, on tâte prudemment le fichier vidéo, et
on le réencode si nécessaire autrement, pour qu'OpenCV ouvre sa version
recodée à coup sûr.

Il se trouve que durant le "freeze" de Debian (c'est à dire la période où
on stabilise la distribution pour en faire un truc en béton pour les
professionnels), quelques bibliothèques video ont été négligées (pas
totalement prioritaires pour les utilisateurs professionnels de Debian qui
sont surtout concernés par l'absence de bug dans l'infrastructure). 

Du coup, il arrivait à OPenCV de déraper jusqu'au point de faire des
fautes de segmentation ... qui ne se produisaient pas si je reprenais
des bibliothèques video du projet debian-multimedia qui a d'autres
contraintes. Afin de ne pas faire éjecter pymecavideo de la distribution
Debian centrale (ce qui l'aurait éjecté d'Ubuntu aussi), j'ai utilisé
une méthode très prudente pour le test des fichiers vidéo, confiant le
soin à un shell externe de se prendre les pires erreurs éventuellement,
pour éviter de bloquer pymecavideo. La période de "freeze" a pris fin il
y a une semaine, ça va rentrer dans l'ordre. Je vais me permettre de
remonter des rapports de bug aux maiteneurs des bibliothèques vidéo,
maintenant qu'ils auront à nouveau ls coudées franches pour remonter les
corrections.

> J'ai un peu modifié l'autotest d'opencvreader, mais il me renvoie
> False : la commande cv.GetCaptureProperty renvoie déserpérement un
> framecount de 0 ::(

Pour toutes les vidéos que tu testes ?

Amitiés,			Georges.

Attachment: signature.asc
Description: Digital signature