Discussion :

[TheGzD]

Bonjour à tous !

Mon problème est lié au nombre d'IPS (10-15) lorsque je fais la capture d'une webcam. En effet j'ai remarqué que la fonction cvRetrieveFrame était assez lente (la doc en parle d'ailleurs) et limitait fortement la vitesse d'acquisition.

Pour bien faire il me faudrait 24-30 IPS sur une machine relativement récente.

Quelqu'un a-t-il déjà rencontré ce problème et l'a résolu ?
L'accélération matérielle (CUDA ?) peut-elle régler le soucis ? A ce propos je ne voudrai pas non plus cantonner mon programme qu'à des cartes NVidia ...

Merci d'avance.

[math_lab]

Il est fort probable que ce soit la camera qui est lente, et pas OpenCV. Quand la doc dit que retrieveFrame est lente, c'est par rapport a grabFrame, et ça n'a d'importance que si tu lis un fichier vidéo et que tu veux juste passer un tas d'images sans les traiter (tu économises le coût de la décompression et peut être de la création de l'image).

Je te conseille aussi d'abandonner la vieille interface C pourrie pour passer a celle du C++ (a moins que tu ne programmes en C, bien entendu) qui devrait te booster un peu tes performances. Mais sinon, non, le GPU ne peux pas grand chose pour toi. La seule façon serait que la bibliothèque ffmpeg (utilisée par OpenCV dans ses versions récentes) supporte l’accélération matérielle. Mais vu qu'on parle de webcam et pas de vidéo ultra HD, ca devrait pas faire de différence.

[TheGzD]

Merci pour ta réponse.

Il est fort probable que ce soit la camera qui est lente, et pas OpenCV.

Euh là j'ai vraiment du mal à comprendre : que je branche 1 seule ou jusqu'à 4 caméras le temps est le même, et d'autre part ce sont tous des modèles différents (de très peu cher à très cher). Si le problème venait d'une ou plusieurs caméras j'aurai une augmentation de la latence avec les dites caméras et ce facteur serait fonction du nombre de caméras utilisées, non ?

Quand la doc dit que retrieveFrame est lente, c'est par rapport a grabFrame, et ça n'a d'importance que si tu lis un fichier vidéo et que tu veux juste passer un tas d'images sans les traiter (tu économises le coût de la décompression et peut être de la création de l'image).

J'ai de multiples caméras qui tournent en parallèle donc en fait ça prend tout son sens vu qu'il me faut synchroniser ces différentes acquisitions. D'autre part, contrairement à ce que tu dis, il est véritablement très important d'avoir de bonnes performances en temps réel alors que pour analyser une vidéo c'est-à-dire faire une analyse "à froid" on s'en fout un peu.

Je te conseille aussi d'abandonner la vieille interface C pourrie pour passer a celle du C++ (a moins que tu ne programmes en C, bien entendu) qui devrait te booster un peu tes performances.

Je ne vois vraiment pas comment rajouter une surcouche pourrait améliorer mes performances ... puis les 2 interfaces sont quasi identiques.

Mais sinon, non, le GPU ne peux pas grand chose pour toi. La seule façon serait que la bibliothèque ffmpeg (utilisée par OpenCV dans ses versions récentes) supporte l’accélération matérielle.

A quoi bon compiler OpenCV pour supporter CUDA alors ?
J'avais lu qu'on avait un gain entre x5 et x10, mais j'aimerai savoir si avec les fonctions dont j'ai parlais j'en profiterai. Et aussi si je ne risquais pas de ne pouvoir plus que faire tourner mon programme sur des systèmes utilisant des GPUs NVidia.

Mais vu qu'on parle de webcam et pas de vidéo ultra HD, ca devrait pas faire de différence.

Là encore ta réponse me laisse perplexe : désolé mais je n'arrive pas du tout à suivre ton raisonnement là ...
Je commence même à me demander si tu ne me trollerais pas

[supernovagm]

j'ai pas l'impression qu'il troll :/

est-ce que tu as essayer sur différentes configurations ? Lire plusieurs webcams simultanément ça demande quand même quelques ressources (surtout avec un traitement ?)

Comment as-tu organiser tes threads ? 1 par webcam ? dans ce cas c'est normal d'avoir les même performance avec 1 et 4 webcams (en imaginant que tu as au moins un processeur quadcore).

as-tu des informations sur les IPS théorique de chacune de tes caméras (données constructeurs) ?

ça peut aussi venir de ta connectique, si t'es en usb 2.0 par example sur un PC portable, les 2 ports usb cote à cote partage en réalité le même port sur la carte mère, donc ton débit théorique est divisé par 2. Essaye en ne branchant qu'une seule webcam (même si les autres ne sont pas utilisées, débranche les) et/ou si tu peux en réduisant la qualité d'acquisition (au moins pour tester).

[math_lab]

Ce qui prend du temps avec les cameras, c'est pas la partie OpenCV mais le fait qu'elles doivent compresser et ensuite envoyer leurs données (dans ton cas, en USB, je suppose). En plus de ça, très souvent les cameras ont quelques fonctionnalités intégrées dans leur hardware (égalisation des couleurs, débruitage, etc.). J'ai travaillé avec divers types de cameras (reliées par câble ethernet) et bien souvent, désactiver le preprocessing hardware, ou changer la taille de l'image permet de passer d'un pauvre 1 IPS a 20 a vide (c'est a dire juste une boucle qui lit et affiche l'image).

Ensuite, l'utilisation de l'interface C++ permet de bénéficier des nombreuses optimisations que les développeurs ont intégré, notamment au niveau de la non-reallocation de la mémoire des cv::Mat (contrairement aux vieilles IplImage), mais aussi de beaucoup de sécurités liées a la mémoire qui évitent d'avoir des problèmes de fuite mémoire qui peuvent être gênants.

Et dernièrement, il me semble que ffmpeg ne doit pas être utilisé sur différents threads (si je me souviens bien, la doc et les patch notes mentionnent des problèmes concernant le décodage de vidéos en simultané). Ça ne m'a pas empêché de le faire jusqu’à présent, mais on sait jamais...

Donc bon, je vois mal comment CUDA peut 1) accélérer ton USB et paramétrer ta webcam, 2) régler des problèmes d'alloc mémoire potentiels, 3) régler les problèmes de multithreading de ffmpeg.

[TheGzD]

Merci pour ta réponse.

Pour l'instant je n'ai pas pu tester sur d'autre configuration que ma machine de développement. A l'heure actuelle je ne fais que la capture et le stockage en RAM des données.

J'utilise 1 seul thread pour toutes mes webcams, mais j'en ai d'autres qui tournent pour d'autres captures et traitements. Par contre la lenteur ne vient pas de là mais bien de la fonction cvRetrieveFrame. En effet sans y faire appel, ma boucle (qui réalise aussi les cvGrabFrame sur toutes les caméras) tourne avec un temps <1ms alors qu'avec l'appel c'est 60-80ms ... "indépendamment du nombre de webcams" (comme dit précédemment j'ai testé avec 1 à 4 caméras).

Selon le site du constructeur les webcams que j'utilise tournent à 30 IPS max en 640x480 : je n'en ai même pas la moitié en 64x48 ...

J'ai une station de bureau (avec 2 cœurs), et à part les caméras je n'ai que mes périphériques de saisie branchés sur l'USB. Le problème se présentant à partir d'une seule caméra et ne devenant pas plus dramatique avec plusieurs je présume que ce n'est pas une limitation du bus.

[math_lab]

Il est vrai que pour du 64*48, c'est pas terrible terrible... Ta version d'OpenCV est a jour ? (la dernière version est la 2.4.2)

[TheGzD]

Il est vrai que pour du 64*48, c'est pas terrible terrible... Ta version d'OpenCV est a jour ? (la dernière version est la 2.4.2)

Oui, c'est bien cette version.
Sinon concernant ce dont tu parlais dans ton précédent post, je n'ai pas l'air d'avoir de fuite mémoire avec les IplImage, par contre je suis intéressé par la désactivation du preprocessing hardware. Si tu as plus d'informations à me donner je suis preneur.

A noter qu'actuellement mon programme tourne en Debug et que j'ai un petit soucis avec des DDL (voir ce post), il y a peut-être un lien de cause à effet mais je n'ai rien trouvé à ce sujet malgré de nombreuses recherches.

[math_lab]

Pour le preprocessing, je crois pas que tu puisses faire ça avec OpenCV. Par contre, les webcams sont souvent livrées avec un driver et un petit utilitaire, il y a peut être moyen de configurer quelque chose. Mais bon, sur des webcams de base, je pense pas qu'il y ait autre chose que la correction des couleurs (ce qui est pas particulièrement intensif au niveau des calculs). De plus, après avoir jeté un coup d'oeil a la doc, retrieveFrame ne fait que décompresser l'image reçue, donc le goulot d’étranglement ne devrait pas provenir de la camera ou du transfert.

J'ai aussi regardé ton post sur les dll, et je sais pas trop quoi dire... Déjà, utilises-tu les commandes GPU d'OpenCV ? OpenCV ne le fait pas automatiquement et seules quelques fonctions sont supportées (certaines ont même une interface un peu différente de la version CPU, je crois). SI tu ne les utilises pas et que ton programme ne marche pas en release, c'est qu'il y a un problème dans ton code (dans 99% des cas, c'est une variable pas initialisée a 0).

[TheGzD]

Je n'utilises pas de commandes spécifiques au GPU, donc c'est assez louche.
Là je viens de tester avec le code (fourni dans la documentation officiel OpenCV) permettant l'acquisition vidéo et la détection du visage et des yeux par haar template et j'ai le même problème avec le chargement des DDL, mon code n'y est donc pour rien.

Je vais réinstaller la bibliothèque et on verra si ça persiste ...

[math_lab]

Je suis pas trop sur que réinstaller la lib fasse grand chose (d'ailleurs, c'est peut être même normal d'avoir ces chargements/déchargements, si ça se trouve...).
Le fait qu'il y ait une différence entre debug et release, par contre, ça me semble être une bonne piste.

[TheGzD]

Je suis pas trop sur que réinstaller la lib fasse grand chose (d'ailleurs, c'est peut être même normal d'avoir ces chargements/déchargements, si ça se trouve...).
Le fait qu'il y ait une différence entre debug et release, par contre, ça me semble être une bonne piste.

La différence est tout à fait normal entre Debug et Release en particulier sur ce genre de problèmes au chargement du style "first chance exception".

[TheGzD]

La réinstallation n'a absolument rien changé ...

EDIT : la suppression et réinstallation des pilotes de ma carte graphique n'a pas non plus changé quoi que ce soit.

[TheGzD]

Grande nouvelle !

Après une journée désespérante passée à arpenter des forums et à bidouiller mon pc dans tous les sens, j'ai finalement récupérer une caméra HD.
Cette dernière fait, sur le papier, comme les autres du 30 IPS max en 640x480, mais si je la branche seule je suis largement à 30 IPS ...

Au moins maintenant je sais chez qui je n’achèterai plus de matériel : merci Moisitech© ...

Mais surtout merci à ceux d'entre vous qui ont bien voulu passer (et perdre) du temps sur ce problème (à la con il faut bien le dire)

[TheGzD]

Pour en revenir aux réglages hardware qui peuvent limiter les performances il faut faire attention à l'auto-exposure qui peut très rapidement poser problème surtout si la caméra est vouée à être en mouvement, ou plus généralement dans un environnement où la quantité de lumière qu'elle recevra variera.

En mettant la propriété CV_CAP_PROP_EXPOSURE à un valeur fixée (< au temps souhaité entre 2 frames) on desactivera cette fonctionnalité automatique : ceci peut drastiquement améliorer les performances !