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)