Discussion :

[misr123]

Bonjour à tous,
Je m'appelle Etienne et je suis développeur informatique.

J'ai une question plus d'ordre théorique que pratique,
Je réalise une application qui doit lire une vidéo d'assez bonne qualité, et qui pendant cette lecture doit acquérir des valeurs sortant d'un capteur USB.

Mon problème est le suivant : le programme est relativement simple, j'ai testé l'acquisition USB avec le capteur dans un autre projet simple et tout se passe bien.
Mais lorsque que j'assemble la vidéo et l'acquisition, très vite (au bout de 5 secondes), le programme plante. J'entend par contre toujours le son de la vidéo, je vois toujours les sorties qDebug() s'afficher etc...
Seulement, la vidéo freeze (et du coup le programme aussi).

Alors j'aimerais avoir votre avis, est-ce que vous pensez que c'est moi qui ai codé comme un pied? Ou bien est-ce que tout simplement les ressources demandées par le programme pour lire la vidéo et effectuer cette acquisition par capteur demande trop de ressources à Qt et provoque l'arret du programme ? Si oui auriez vous une solution à proposer ?

Cordialement, et merci pour le temps que vous prendez à lire mon message
Etienne

[LittleWhite]

Bonjour,

Vous mettez comme titre : "trop de mémoire" et vous n'en parlez plus par la suite. Avez-vous vérifier dans le gestionnaire de fichier, ou autre ?
Avez-vous testé de désactiver l'acquisition et de ne lire que la vidéo dans Qt et voir comment cela réagit.

[misr123]

Bonjour,
J'ai résolu le soucis sur un autre forum avec la fonction QCoreApplication::processEvents() dans ma boucle qui procédait à l'acquisition.

Je copie-colle la réponse de la personne qui m'a aidé si cela pourrait aider quelqu'un ici par le suite :

"Avec les systèmes souris-fenêtres on fait de la programmation événementielle :
On met en place une IHM, fenêtres, boutons, zones de saisie... et on attend qu'il se passe quelque chose : un événement.
L'événement est souvent une action de l'utilisateur. Il clique sur un bouton, appuie sur la lettre C, déroule un menu...
Ou un timer se termine : événement. Ou ma fenêtre passe au premier plan : événement. Ou je la ferme : événement.
Au moment de app.exec(), Qt lance une boucle qui attend les événements et les transmet au code chargé de les gérer.
Bref.
Quand tu lances une vidéo, tu remarques que l'application continue à répondre : on peut changer le fenêtre de taille, ouvrir les menus, les widgets se redessinent, etc. C'est parce que pendant qu'il joue la vidéo Qt rend la main régulièrement à la boucle d'événements, il n'accapare pas toutes les ressources du PC sinon tout serait figé en dehors de la vidéo. D'accord ?
C'est pour cela que lorsqu'on lance une tâche comme l'acquisition qui prend du temps et qui accapare toutes les ressources il faut régulièrement "redonner la main" à la boucle d'événements. C'est le rôle de processEvents () : "va voir s'il n'y a pas un événement en attente, et si oui, traite le, puis tu reviens".

Attention : plus l'appel de processEvents sera fréquent, plus ton appli sera fluide et plus ta tâche sera lente. Il y a un réglage à faire, par exemple appeler processEvents tous les 10 ou 100 ou 1000 tours de boucle sur ce modèle

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
    int count = 0;  
 
    while (! endOfTask ())  
    {  
        // fais des choses  
 
        ++count;  
        if (count % 100 == 0)  
        {  
            QCoreApplication::processEvents ();  
        }  
    } // while

C'est du faux multitâche : une tâche une fois lancée doit régulièrement lâcher la grappe à la CPU. Il n'y a pas de conflit d'accès à des ressources communes entre les tâches.
Qt permet d'utiliser un vrai multitâche avec l'emploi des threads (classe principale QThread) mais il y a des contraintes (par exemple, un seul thread peut manier l'interface graphique)."