Discussion :

[Frere Tuck]

Bonjour ,

Tout est plus ou moins dit dans le sujet du post : Existe-t-il un default allocator presenter pour le VMR9 ?

Dans la MSDN, il est indiqué que l'interface n'est pas divulguée parce que blablabla au sujet des surfaces Direct3D et de la méthode AllocateSurfaceHelper ... Bref ce n'est pas cette partie qui m'interesse particulièrement ... mais plutôt le fait que dans le VMR7, qui lui a un default AP, il y a une interface IVMRWindowless.

Donc, en fait, je me demandais si quelqu'un avait déjà codé ce genre de choses (Un allocator presenter pour VMR9 possédant, en plus des interfaces permettant de faire un AP, une interface utile au positionnement de la surface Direct3D dans la fenêtre parente et cie - IVMRWindowless plus ou moins) ... Auquel cas ça me simplifierait grandement la tâche

Merci

PS : J'suis pas sûr d'avoir un post compréhensible Désolé si c'est le cas

[moldavi]

Existe-t-il un default allocator presenter pour le VMR9 ?

Salut,

je ne comprends pas la question. Qu'est-ce que tu appelles un "default allocator presenter pour le VMR9"?

La VMR9 peut-être utilisée dans plusieurs modes de rendu. Avec le mode "WindowLess", c'est l'interface "IVMRWindowlessControl9" qu'il faut utiliser.

[Frere Tuck]

Bonjour,

je ne comprends pas la question. Qu'est-ce que tu appelles un "default allocator presenter pour le VMR9"?

Un allocator presenter qui, à l'instar de celui du VMR7, est associé au VMR9.

La VMR9 peut-être utilisée dans plusieurs modes de rendu. Avec le mode "WindowLess", c'est l'interface "IVMRWindowlessControl9" qu'il faut utiliser.

Effectivement... Mais si on implémente un "allocator presenter", pour pouvoir l'utiliser, il faut être dans le mode renderless... et donc dans ce mode, il n'est "pas possible" - du moins via une interface directe et existante - de gérer la position des surfaces Direct3D dans une fenêtre...

Voili voilou ...

[moldavi]

En renderless, c'est "DirectxGraphics" qui pilote l'affichage, avec l'interface "IDirect3DDevice9". Pour ton AP, et selon le type d'intervention que tu veux faire, tu dois le gérer comme une "meshe", en deux dimensions bien sur.

[Frere Tuck]

Bonjour ,

Bon j'ai trouvé ce que je voulais faire ... Pour n'avoir l'image que sur une partie de la fenêtre, je n'ai qu'à utiliser cette méthode :

IDirect3DDevice9:resent(..., RECT* dest, HWND hWnd, ...)



Par contre, j'aurais une autre question : Est ce que tu connaitrais l'existance d'un MultiVmr9 modifié ... cad sans bug et mieux codé ?

Merci en tous cas

[moldavi]

Par contre, j'aurais une autre question : Est ce que tu connaitrais l'existance d'un MultiVmr9 modifié ... cad sans bug et mieux codé ?

On ne doit pas parler du même multivmr9.

Des bugs peut-être mais je ne les ai pas encore trouvé. Si tu regardes bien le code, je dirais plutôt qu'il est blindé, avec pas mal de bloc "try-catch", et un test systématique de validité de pointeur avant leur utilisation. Je serai curieux que tu me fasses part de ces bugs afin que je les constate.

"Mieux codé": pour l'instant, je n'ai vu aucun code qui gére aussi bien la vidéo dans un environnement 3D, sans posséder de codec vidéo super élaboré. Même le "...multi...bridge.." enfin un truc dans ce genre, est un gouffre en temps processeur. Et pour avoir longuement cherché je ne connais que ces deux codes. Et pour le second, il ne concerne pas la 3D.

"MultiVmr9 modifié": le multivmr9 est incomplet, mais c'est très facile de coder les fonctionnalités qui lui manque. Il a même été fait de tel sorte qu'il est très facile de lui donner son propre environnement 3D, juste en utilisant la DLL compilée.

[Frere Tuck]

Bonjour ,

On ne doit pas parler du même multivmr9.

Si si on parle bien du même

Si tu regardes bien le code, je dirais plutôt qu'il est blindé, avec pas mal de bloc "try-catch", et un test systématique de validité de pointeur avant leur utilisation.

Mouais ... Regarde la méthode CMultiVMR9Wizard::GetSourceInfo_ ... Tu ne peux pas dire qu'elle soit très sûre ... Et ce n'est qu'un exemple.

"Mieux codé": pour l'instant, je n'ai vu aucun code qui gére aussi bien la vidéo dans un environnement 3D, sans posséder de codec vidéo super élaboré. Même le "...multi...bridge.." enfin un truc dans ce genre, est un gouffre en temps processeur. Et pour avoir longuement cherché je ne connais que ces deux codes. Et pour le second, il ne concerne pas la 3D.

Le "mieux codé", c'était pour la méthode de codage en fait ... Aucune convention, des bouts de code identiques qui se répètent à tout va, etc etc.
Je connais pas le "...multi...bridge.."

"MultiVmr9 modifié": le multivmr9 est incomplet, mais c'est très facile de coder les fonctionnalités qui lui manque. Il a même été fait de tel sorte qu'il est très facile de lui donner son propre environnement 3D, juste en utilisant la DLL compilée.

Vi j'ai vu ça via le sample GamePlayer

Bonne journée

[moldavi]

Bonjour.

Si si on parle bien du même

Mouais ... Regarde la méthode CMultiVMR9Wizard::GetSourceInfo_ ... Tu ne peux pas dire qu'elle soit très sûre ... Et ce n'est qu'un exemple.

Tu peux penser que ce code n'est pas sur, mais ce n'est pas un bug. C'est la méthode de fonctionnement de la vmr9 qui est ainsi.

Tu n'as pas le choix si tu veux utiliser la vmr9. Tu dois lui fournir un pointeur, sinon elle sera incapable de fonctionner.

Le "mieux codé", c'était pour la méthode de codage en fait ... Aucune convention, des bouts de code identiques qui se répètent à tout va, etc etc.

Ok, je pense comprendre ton point de vue.

La multivmr9 n'est pas une dll classique et n'est pas codée comme une dll ou un exécutable dont tu as peut-être l'habitude.

La multivmr9 est un objet COM, et il est programmé tel quel. Tous ces bouts de code qui te paraissent redondants, ont leur raison d'être. Cette dll gère le "factoring". Elle doit se gérer en interne, comme un programme classique, mais elle doit en plus gérer les objets utilisés par les différents programmes qui lui en font la demande.

Rien ne t'empêche d'en faire une dll classique avec du code qui sera nettement plus simple. Sauf que:

- personnellement, je n'ai jamais réussi à faire de dll qui proposent des exportations de classes, de façon satisfaisantes.

- les classes de la multivmr9 sont intimement liées, ce qui complique un peu la chose.

Tu peux mettre le code dans un exécutable (pour la maintenance, je préfère l'utiliser en tant que dll).

Je connais pas le "...multi...bridge.."

J'ai retrouvé le nom: "GMFBridge". Cette dll permet de mixer plusieurs vidéos, (la plupart des codecs ne le permettent pas).

[Frere Tuck]

Bonjour ,

Tu peux penser que ce code n'est pas sur, mais ce n'est pas un bug. C'est la méthode de fonctionnement de la vmr9 qui est ainsi.

Tu n'as pas le choix si tu veux utiliser la vmr9. Tu dois lui fournir un pointeur, sinon elle sera incapable de fonctionner.

Bien sûr, sauf que faire un cast sur un pointeur dont on ne connait (presque) rien de son existence c'est pas clean ... Quelque chose de meilleure aurait été de regarder si la source (caractérisée par le pointeur) était toujours présente dans leur list<> des sources ... ça aurait été beaucoup plus clair et on n'aurait pas été obligé de regarder, en amont, ce qu'ils mettaient dans ce pointeur

Ok, je pense comprendre ton point de vue.

Je n'ai rien contre le code lié à la techno COM (au contraire) et je ne renie en rien la méthode adoptée pour publier cette dll* ... Cependant, je persiste. Il y a du code redondant qui n'a pas lieu d'être. Par exemple :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
    list<CMultiVMR9_Frame*>::iterator start, end, it;
 
    start = m_listFrames.begin();
    end = m_listFrames.end();
 
    for( it = start; it != end; it++)
    {
        pFrame = (CMultiVMR9_Frame*)(*it);
        if( dwID == pFrame->m_dwID )
        {
            pFrameRequested = pFrame;
            break;
        }
    }

Tu le vois dans n'importe quelle méthode de la classe CMultiVMR9MixerControl lorsqu'il faut récupérer des infos sur une frame ... Je ne vois pas l'utilité de faire ce genre de choses ... si ce n'est de rajouter des lignes de codes pour rien
Je ne prétend en aucun cas faire du code propre mais de voir les mêmes bouts de code qui se répètent un peu partout c'est, au début, chiant et ensuite ça devient vite embrouillant

J'ai retrouvé le nom: "GMFBridge". Cette dll permet de mixer plusieurs vidéos, (la plupart des codecs ne le permettent pas).

Je vais y jeter un oeil Merci

A++

*: D'ailleurs en ce qui concerne les pointeurs intelligents, ils connaissent pas eux ... arf

[moldavi]

Bonjour.

Ton point de vue est tout à fait louable.

Chaque programmeur à sa manière de coder, et il est souvent très difficile de comprendre la manière de coder des autres développeurs.

Il est tout aussi difficile de faire un code didactique, surtout dans le cas d'une application multithreadée, liée à un environnement en 3D.

Je ne vais pas me positionner en tant que défenseur de ce code, mais je vais essayer de te donner un autre point de vue.

Ce code n'est peut-être pas parfait, imcomplet oui.

Bien sûr, sauf que faire un cast sur un pointeur dont on ne connait (presque) rien de son existence c'est pas clean ...

Ce raisonnement me semble faux. Si tu regardes bien, la méthode "GetSourceInfo_" est une méthode privée. Elle n'est donc pas destinée à être utilisée dans un autre cadre que le fichier "Wizard.cpp". Elle ne peut pas provoquer d'erreur parce qu'elle est utilisée en interne et que par conséquent on est pas sensé faire du code non sur...

On connaît l'existence du pointeur! Si tu regardes encore d'un peu plus près, les méthodes qui appellent cette fonction ne lui transmettent pas un pointeur venu de nulle part mais bien un pointeur de la liste concernée:

Exemple: la méthode "Clean_" appelle "Detach" avec comme paramètre le fameux pointeur qu'elle a obtenue depuis la liste (m_listVideoSources), et ensuite "Detach" appelle "GetSourceInfo_" avec ce fameux identifiant qui ne vient pas de nul part.
On pourrait dire ici qu'il y a de la redondance dans la vérification de la validité de ce pointeur. On pourrait même en conclure que ce code est sur...

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
list<CMultiVMR9_Frame*>::iterator start, end, it;
 
    start = m_listFrames.begin();
    end = m_listFrames.end();
 
    for( it = start; it != end; it++)
    {
        pFrame = (CMultiVMR9_Frame*)(*it);
        if( dwID == pFrame->m_dwID )
        {
            pFrameRequested = pFrame;
            break;
        }
    }

Tu le vois dans n'importe quelle méthode de la classe CMultiVMR9MixerControl lorsqu'il faut récupérer des infos sur une frame ... Je ne vois pas l'utilité de faire ce genre de choses ... si ce n'est de rajouter des lignes de codes pour rien

.

Ce que je comprends là c'est que pour toi, ce bout de code ne sert à rien?

Si c'est bien ce que je dois comprendre, je dirais au contraire que cette boucle est indispensable!!!

1ère chose: je pense que si ce bout de code est à chaque fois présent, alors qu'il aurait très bien pû être une méthode, c'est à des fins d'optimisation.
Je pense que de faire de ce code une méthode "inline", ne garantie pas que le compilateur l'inline. Il est vrai que je n'ai pas vérifié, mais je ne pense pas que les concepteurs de cette dll ne l'ont fait par hasard, mais plutôt dans ce sens (je peux me tromper bien sur).

2ème chose: ce code est indispensable de part le fonctionnement de la vmr9. Lorsque la vmr9 fait son travail et te donnes par exemple une trame vidéo, elle te passe en même temps l'identifiant du graphe concerné (le fameux pointeur réinterpretcasté). Tu ne fait pas un bout de code pour chaque vidéo mixée! tu utilises un seul code qui est capable de gérer tes différentes vidéos (et sans erreur) grâce au fait que tu parcours ta liste, et que tu associes l'identifiant que te donnes la vmr9, aux bonnes données de ta liste. Je dirais même que c'est tout le contraire d'un code peu sur.

*: D'ailleurs en ce qui concerne les pointeurs intelligents, ils connaissent pas eux Rolling Eyes ... arf

Tu exagères un petit peu. On peut dire que les codeurs de chez microsoft ne sont pas les meilleures exemples du monde, mais bon.
Regardes l'exemple "VMR9Allocator", il utilise les "CComPtr".

Je veux juste te donner une autre vision de ce code. On peut en tirer des choses très intéressantes et très efficaces. Si tu prends le temps (et il en faut) pour bien assimiler ce code, je pense que tu pourras en faire une version tout aussi efficace et peut-être même plus, de ce code et qu'il pourra parfaitement répondre à tes besoins.

Si par hasard, tu trouves un code qui fait la même chose, ce serait sympa de m'en faire part. Je pense que ce code peut-être conçu de manière très différente (ça fait un peu son charme et son intérêt), et toute méthode de conception est bonne à connaître.

[Frere Tuck]

Bonjour ,

Chaque programmeur à sa manière de coder, et il est souvent très difficile de comprendre la manière de coder des autres développeurs.

Oui enfin là c'est plus de l'embrouillage que de la difficulté

Ce raisonnement me semble faux. Si tu regardes bien, la méthode "GetSourceInfo_" est une méthode privée. Elle n'est donc pas destinée à être utilisée dans un autre cadre que le fichier "Wizard.cpp". Elle ne peut pas provoquer d'erreur parce qu'elle est utilisée en interne et que par conséquent on est pas sensé faire du code non sur...

On connaît l'existence du pointeur! Si tu regardes encore d'un peu plus près, les méthodes qui appellent cette fonction ne lui transmettent pas un pointeur venu de nulle part mais bien un pointeur de la liste concernée:

Exemple: la méthode "Clean_" appelle "Detach" avec comme paramètre le fameux pointeur qu'elle a obtenue depuis la liste (m_listVideoSources), et ensuite "Detach" appelle "GetSourceInfo_" avec ce fameux identifiant qui ne vient pas de nul part.
On pourrait dire ici qu'il y a de la redondance dans la vérification de la validité de ce pointeur. On pourrait même en conclure que ce code est sur...

Très bien... Mais si ce code était aussi sûr que tu ne le dis, il ne devrait pas provoquer des erreurs mémoires même avec une mauvaise utilisation de cette DLL ... Ce qui est le cas avec l'appli que je développe

Ce que je comprends là c'est que pour toi, ce bout de code ne sert à rien?

Heu ... Je n'ai jamais écris ça moi .... Bon d'accord à la relecture ça peut paraître tendancieux, mais ce n'est pas ce que j'ai voulu dire

1ère chose: je pense que si ce bout de code est à chaque fois présent, alors qu'il aurait très bien pû être une méthode, c'est à des fins d'optimisation.

Mouais ... Si on en fait une méthode, elle ne sera pas appellée 36000 fois par secondes ... Regarde les méthodes qui utilisent ce code. Ce sont des SetAlpha, GetAlpha, etc. qui ne sont pas (ou presque pas) au "centième de nanosecondes près"

2ème chose: ce code est indispensable de part le fonctionnement de la vmr9. Lorsque la vmr9 fait son travail et te donnes par exemple une trame vidéo, elle te passe en même temps l'identifiant du graphe concerné (le fameux pointeur réinterpretcasté). Tu ne fait pas un bout de code pour chaque vidéo mixée! tu utilises un seul code qui est capable de gérer tes différentes vidéos (et sans erreur) grâce au fait que tu parcours ta liste, et que tu associes l'identifiant que te donnes la vmr9, aux bonnes données de ta liste. Je dirais même que c'est tout le contraire d'un code peu sur.

Ha mais y'a aucun problème là-dessus

Tu exagères un petit peu. On peut dire que les codeurs de chez microsoft ne sont pas les meilleures exemples du monde, mais bon.
Regardes l'exemple "VMR9Allocator", il utilise les "CComPtr".

Je ne fais pas le procès de tous les samples du SDK ... Même si on en serait bien tenté . D'accord je peux comprendre que ce ne soit pas la même personne qui ai développé tous les samples d'une partie du SDK mais quand même ... Y'a pas de cahiers des charges chez Microsoft ?
Et puis, les samples qui utilisent les pointeurs intelligents, tu peux les compter sur les doigts d'une main (Au moins pour la partie DirectShow)

Si par hasard, tu trouves un code qui fait la même chose, ce serait sympa de m'en faire part. Je pense que ce code peut-être conçu de manière très différente (ça fait un peu son charme et son intérêt), et toute méthode de conception est bonne à connaître.

J'y travaille ... Seulement si je refais cette DLL, c'est avant tout pour avoir un environnement multi-graph qui me permettra de mixer plusieurs flux de manière simpliste. Donc je ne suis pas sûr que ça t'interesserai
Enfin ... tu pourra y jeter un oeil quand l'ensemble sortira

A++

[moldavi]

Salut, Frere Tuck.

Ce code n'est pas de l'embrouillage. Si vraiment il l'était, j'aurais du mal à le comprendre me considérant comme un développeur débutant.

Tu me dis que ce code provoque des erreurs de mémoire. Je n'ai pas encore constaté cet état de fait et je n'ai pas encore rencontré de problème avec mon code basé sur cette DLL. Si tu veux, je veux bien regarder avec toi ce qui ne va pas.

Pour "mixercontrol.cpp" et la boucle sytématiquement utilisée. J'imagine que pour toi, la bonne approche c'est de coder une méthode qui effectue ce travail. Est-ce que l'on peut vraiment jeter la pierre à ce code juste pour cette raison...

L'optimisation dont je parlais plus haut au niveau de cette boucle, ne se situe pas par rapport au nombre d'appel de cette fonction mais à la rapidité même de celle-ci. On reste sur la pile d'appel de la fonction et les itérateurs de la liste seront placés dans les registres du processeur, surement à une position très favorables pour le parcours de la liste (j'admet, c'est du titillage, mais attention quand même, c'est du code multithreadé, et récupérer les itérateurs dans des variables n'est peut-être pas si anodin que ça...).

Les samples du SDK, ne sont que des exemples, les conventions de codage c'est pour le travail en équipe. Les conventions de base sont respectées: p pour pointeur, m_ pour membre de classe, g_ pour globale, etc...

Le GMFBridge te conviendra peut-être mieux, si tu veux juste faire du mixage vidéo. Je te remercie de pouvoir m'y faire jeter un oeil .

[Frere Tuck]

Bonjour ,

Est-ce que l'on peut vraiment jeter la pierre à ce code juste pour cette raison...

J'ai bien dit que ce n'était pas le seul truc qui me gênait dans ce code

Les samples du SDK, ne sont que des exemples, les conventions de codage c'est pour le travail en équipe. Les conventions de base sont respectées: p pour pointeur, m_ pour membre de classe, g_ pour globale, etc...

Mhhh ... Pas tout le temps il me semble ... Il y a quand même des samples qui sont méchamment baclés des fois

Le GMFBridge te conviendra peut-être mieux, si tu veux juste faire du mixage vidéo.

Pour le peu de temps que j'y ai accordé, il m'a semblé plutôt intérressant ... Maintenant, je n'ai pas forcément le temps de m'y plonger sérieusement (encore plus après ce que tu as écris plus haut : "Même le "...multi...bridge.." enfin un truc dans ce genre, est un gouffre en temps processeur" )

Je te remercie de pouvoir m'y faire jeter un oeil .

Tu devrais recevoir un mp d'ici peu

A++

[Frere Tuck]

Bonjour ,

Après beaucoup de déconvenues, j'ai finalement trouvé la raison à mes problèmes avec cette DLL ...

Lorsque je créais le filtre VMR9, je lui demandais d'avoir 4 pins en entrée... Or il semble que cette opération soit fortement déconseillée

Mon code qui ressemblait (dans les grandes lignes et sans vérification de cas d'erreur) à :

Code :

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

1
2
3
4
5
6
7
8
9
 
m_pVmr9.CoCreateInstance(CLSID_VideoMixingRenderer9);
 
pGraphBuilder->AddFilter(m_pVmr9, L"Video Mixing Renderer 9"); // IGraphBuilder* pGraphBuilder
 
CComQIPtr<IVMRFilterConfig9> pConfig(m_pVmr9);
 
pConfig->SetRenderingMode(VMR9Mode_Renderless);
pConfig->SetNumberOfStreams(4);

est devenu la même chose avec la dernière ligne mise en commentaire.

Voila voila.

Bon courage à tout ceux qui développeront avec cette DLL

NB : "pConfig->SetNumberOfStreams(1);" ne fonctionne pas mieux ... Méthode prescrite pour moi donc