IMemAllocator: GetBuffer se bloque

Question

Quelqu'un sait-il des raisons pour lesquelles IMemAllocator:GetBuffer (Directshow) se bloque, en dehors de tous les échantillons en cours d'utilisation?

J'ai une application DirectShow qui utilise GMFBridge by Geraint Davies pour connecter deux graphiques. Le GMFBridge est utilisé pour pouvoir changer d'entrée, mais je ne change pas dans cette situation. L'application capture l'audio et la vidéo, et devrait le faire sans arrêt. Mais après environ 10 heures, ça s'arrête. J'ai trouvé à la fois audio et vidéo est resté coincé dans un appel à IMemAllocator: GetBuffer:

/* _COM_SMARTPTR_TYPEDEF(IMemAllocator, IID_IMemAllocator); */ 
/* IMemAllocatorPtr m_pCopyAllocator; */ 

hr = m_pCopyAllocator->GetBuffer(&pOut, NULL, NULL, 0); 

Si tous les échantillons sont en cours d'utilisation, cette fonction peut bloquer, mais je suis sûr que ce n'est pas le cas. Deux threads appellent cette fonction, un pour la vidéo et un pour les échantillons audio. Le thread audio bloque d'abord, et après que le GetBuffer a renvoyé un tampon pour près de 60 échantillons vidéo, le fil vidéo se bloque aussi. (environ 2 secondes plus tard)

Après presque 8 heures, les deux threads continuent pendant une courte période, d'abord le thread audio, et après que 45 tampons pour les échantillons audio ont été renvoyés, le thread vidéo se débloque également. Comme les deux threads ne bloquent pas en même temps, il me semble qu'il n'y a pas de problème avec tous les échantillons utilisés. Le stacktrace montre une fonction à l'intérieur de quartz.dll est appelé à ce moment-là

MISE À JOUR

On dirait qu'il y avait un memoryleak causé par les filtres de décodeur déjà installé sur le PC. Le graphique incluait le décodage de mpeg, par exemple le décodage audio utilisait un décodeur de cyberlien. Après l'installation de ffdshow, le décodeur audio + vidéo ffdshow a été utilisé à la place, et le problème semble avoir disparu. Leçon apprise, ne dépend pas automatiquement des filtres existants.

Answer 1

Je ne suis pas sûr de pouvoir déboguer cela à partir des informations fournies. Pouvez-vous créer un fichier journal (créez un fichier vide c: \ gmfbridge.txt, exécutez jusqu'à ce qu'il se bloque, puis compresser le fichier et l'envoyer par courrier électronique). En outre, si vous définissez vos symboles avec _NT_SYMBOL_PATH, vous pouvez regarder la trace de la pile pour voir où se trouvent les différents threads dans quartz.dll.

G