faire une pause dasn un graphe d'encodage [DirectShow] - C++ - Programmation
Marsh Posté le 28-04-2010 à 12:29:14
Bonjour,
Quand tu veux faire une pause tu utilises la méthode stop()?
Et quand tu veux stopper, est ce que tu utilises pause()?
Marsh Posté le 28-04-2010 à 14:07:26
breizhbugs a écrit : Bonjour, |
Le truc c'est que la pause n'arrête pas le graphe, elle continue de faire circuler les données dans les filtres mais bloque uniquement le rendu dans le fileWriter. (voir doc msdn)
Donc j'ai mes processeurs qui continuent a bosser sur l'encodage ^^, mais le principe de la pause est de libérer les ressources processeur.
hors avec un stop(), les traitements se terminent et le graphe s'arrête en me libérant les unités de calcul.
seul problème, le fichier se sortie est incomplet !
il me faudrait un moyen d'écrire à la suite du fichier les informations et non ré-écraser les données présentes avant la pause !
PS: j'ai du mal a voir si ton message était ironique !
Marsh Posté le 28-04-2010 à 14:25:40
Non, avec un Pause() les données ne vont pas éternellement aller vers le renderer. Celui-ci buffurisera peut-être un peu, mais ensuite il bloquera le graphe. Donc ta charge CPU retombera.
Marsh Posté le 28-04-2010 à 15:10:46
Riot a écrit : Non, avec un Pause() les données ne vont pas éternellement aller vers le renderer. Celui-ci buffurisera peut-être un peu, mais ensuite il bloquera le graphe. Donc ta charge CPU retombera. |
J'ai essayé de faire un Pause() plutôt qu'un Stop() mais rien n'y change, mon graphe tourne toujours, et mes processeurs tournent toujours a 100%, même pour une grosse séquence d'image (environ 2 minutes de vidéo avi en sortie)
J'ai réussi a trouver un élément en plus, le Stop() fonctionne bien, mais apparemment le muxer avi finalise le fichier final quand on utilise celui ci. Ce qui expliquerait l'écrasement des données dans mon fichier final.
je vais poursuivre mes recherches de ce coté,
peut être existe-il une alternative qui réalise la même chose que le muxer ?
Marsh Posté le 28-04-2010 à 15:16:05
Tu utilises quoi comme filtres dans ton graphe ?
Quelle est la taille de tes images et le type de compression ?
Si tu fais un .avi, tu es obligé d'utiliser un muxer ; et avec n'importe lequel (sauf si tu en développes un toi-même) il finalisera le fichier de sortie lorsque tu feras un Stop().
Marsh Posté le 28-04-2010 à 15:25:36
Riot a écrit : Tu utilises quoi comme filtres dans ton graphe ? |
J'utilise un filtre perso en source, je redirige ça vers mon encoder (DivX ou autre), ensuite muxer et FileWriter.
j'ai des images assez grandes, puisque mosaïques non compressées 1500*900 mais je penses pas que ce soit le problème.
Je crois que je vais devoir mettre les mains dans le moteur ^^
en tout cas merci pour les tuyaux
Marsh Posté le 28-04-2010 à 15:32:29
Très bon forum : http://social.msdn.microsoft.com/F [...] nt/threads
Marsh Posté le 28-04-2010 à 15:40:03
Oui j'étais ironique, mais bon comme tu ne détaillais pas le pourquoi du comment, je pouvais pas savoir^^
Sinon, ta pause, elle sert a avancer dans la lecture sans enregistrer?
Peux tu mettre un screenshot de ton graph avec graphedit pour voir a quoi il ressemble?
Marsh Posté le 28-04-2010 à 15:53:46
breizhbugs a écrit : Oui j'étais ironique, mais bon comme tu ne détaillais pas le pourquoi du comment, je pouvais pas savoir^^ |
Non en gros, ma pause doit arrêter le graphe, pour pouvoir le reprendre plus tard sans problèmes et avoir au final un fichier compressé avi san pertes de données, mais apparemment c'est pas possible avec un Stop().
Marsh Posté le 28-04-2010 à 16:06:46
Quand tu dis que tu as un filtre perso en source et que la fonction pause continue d'alimenter l'encodage, peut etre que le problème vient du fait que ton filtre source ne gère pas la pause (je dis ça mais en fait j'y connait rien la dedans hein, c'est juste une hypothèse....)?
Marsh Posté le 28-04-2010 à 16:10:38
breizhbugs a écrit : Quand tu dis que tu as un filtre perso en source et que la fonction pause continue d'alimenter l'encodage, peut etre que le problème vient du fait que ton filtre source ne gère pas la pause (je dis ça mais en fait j'y connait rien la dedans hein, c'est juste une hypothèse....)? |
si si il gère la pause et tout pas de soucis la dessus, j'ai testé de bloquer directement l'alimentation du graphe à la source ^^ marche pas non plus
Marsh Posté le 28-04-2010 à 16:18:15
Bah c'est pas normal alors. Si ton proc est à 100% c'est que tu as une attente active quelque part (ton filtre peut-être ?)
Marsh Posté le 28-04-2010 à 16:24:53
Riot a écrit : Bah c'est pas normal alors. Si ton proc est à 100% c'est que tu as une attente active quelque part (ton filtre peut-être ?) |
Ouai je vais revérifier pour la n-ième fois XD
Marsh Posté le 28-04-2010 à 20:14:22
Poste le code de ton filtre pour voir a quoi ça ressemble si c'est pas indiscret...
Marsh Posté le 28-04-2010 à 11:54:34
Bonjour,
je suis bloqué sur un problème qui m'embête maintenant depuis quelques jours !
je développe un application qui permet d'encoder des vidéos au format AVI à partir de séries d'images envoyée a partir d'un filtre source
et de l'écrire à partir d'un filtre de rendu FileWriter.
j'essaye d'intégrer une fonctionnalité qui permet de mettre en pause ce graphe.
(j'ai une petite barre de progression qui indique l'état d'avancement de l'encodage)
lorsque je fais un appel a media_control->Stop(), le graphe s'arrête correctement !
quand je veux reprendre l'encodage je fais appel a media_control->Run().
le Problème: A la fin de l'encodage, le fichier avi ne comprend que la partie qui va de l'instant ou j'ai fait ma pause à la fin de la video.
Quelqu'un connait-il un moyen d'écrire a la suite du fichier après un stop et non d'écraser les informations déjà présentes dans le fichier ???
en espérant qu'un pro de DirectShow passe par ici ^^
Bonne journée
PS: j'ai 200 frames à 25 frames par secondes donc 8 secondes de vidéo en sortie
quand je fais une pause au niveau de l'encodage de la 100e frame et que je reprends, mon fichier avi final ne fait que 4 seconde,
et ces 4 secondes sont les 4 dernières seconde de ma séquence.