GraphEdit sous Windows 7.1 en 64 bits

J'ai déjà eu l'occasion d'évoquer le logiciel GraphEdit qui rend beaucoup de services à ceux qui font de la programmation avec l'architecture DirectShow de Microsoft.

J'ai eu depuis plusieurs jours un problème qui m'ennuie beaucoup: Quand on ouvre GraphEdit et qu'on veut y ajouter un filtre de la catégorie directshow, alors le programme se plante et ferme abruptement. Il était donc devenu impossible de composer à la main un filtre.

Pour ceux qui auraient le même problème, je donne tout de suite la solution qui a résolu le problème chez moi: c'est le filtre LAV Video Decoder qui est le responsable, comme c'est indiqué sur cette page web.  En le désinstallant tout revient à la normale. Voir ici comment faire par la méthode basique, mais on peut le faire beaucoup plus aisément avec mon logiciel Filmerit. Notons quand même que certaines pages web parlent d'un  problème identique provoqué par d'autres filtres mal installés ou non compatibles. Dans l'un d'eux le problème a été résolu en mettant à jour ffdshow. En tous cas, cela semble toujours être lié à un filtre directshow. Il est donc inutile de chercher à réinstaller graphedit, voire Windows... Si on a de la chance, une restauration système marche. Sinon, en tâtonnant il faut chercher quels sont les derniers filtres qui ont pu être installés par une application  ou une autre. Chez moi, c'est Video to Video qui avait installé les filtres LAV, y compris LavVideo.ax

Ce problème m'a conduit à effectuer diverses recherches qui m'ont permis de progresser dans la compréhension  de GraphEdit, des filtres directshow et du fonctionnement de la base de registres sous Windows 7.1 en 64 bits.

Pour commencer, j'ai découvert qu'il y avait deux versions de GraphEdit: une version 32 bits et une version 64 bits. La manière officielle de les télécharger est de télécharger tout le Windows 7.1 SDK.
En ce qui me concerne, je télécharge depuis le site de Microsoft un fichier ISO du DVD de Windows SDK 7.1, et je le grave (par exemple avec ImgBurn) sur un DVD. Ensuite pour n'installer que les appli qui m'intéressent, j'explore le DVD obtenu, pour trouver le dossier: \Setup\WinSDKWin32Tools dans lequel je double clique sur winsdkwin32tools_x86.msi
Cela crée un dossier C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1\Bin dans lequel se logent tous les outils utiles: notamment GraphEdt.exe qui est la version 32 bits du programme, et dans le sous-dossier X64, la version 64 bits qui porte le même nom.

On peut différencier les 2 en en lançant un et en ouvrant le Gestionnaire des tâches. Celui qui est 32 bits apparaît avec une mention *32, alors que l'autre reste graphedt.exe seul. Les deux peuvent fonctionner simultanément. Pour me faciliter la tache je les renomme bien sûr en graphedit32.exe et graphedit64.exe

Pour que GraphEdit puisse espionner le graphe d'une autre application, et aussi ouvrir les pages de propriétés des filtres et pins qu'il affiche, il faut aussi installer deux dll: proppage.dll et evrprop.dll. Ces deux fichiers existent aussi en versions 32 bits et 64 bits, respectivement dans le dossier Bin et son sous-dossier x64. On les installe avec regsvr32.exe qu'on trouve dans les deux dossiers C;\Windows\System32 et c:\Windows\SysWow64. C'est un peu délicat car c'est en mode ligne de commande qu'il faut travailler dans une fenêtre de commande DOS.  Pour cela je crée avec notepad un fichier install.bat qui contient le texte suivant:

C:\WINDOWS\System32\Regsvr32.exe "C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1\Bin\proppage.dll"

C:\WINDOWS\System32\Regsvr32.exe "C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1\Bin\evrprop.dll"

C:\WINDOWS\SYSWoW64\Regsvr32.exe "C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1\Bin\x64\proppage.dll"

C:\WINDOWS\SYSWoW64\Regsvr32.exe "C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1\Bin\x64\evrprop.dll"

Quand je double clique sur le fichier install.bat, j'obtiens 4 messages d'installation réussie, et alors mes deux versions de GraphEdit sont pleinement opérationnelles.

Maintenant, si on ouvre graphedit32 et graphedit64 et qu'on tape CTRL+F pour charger des filtres, et qu'on clique sur Directshow Filters pour déplier le noeud et obtenir l'affichage de tous les filtres de la catégorie directshow, on n'obtient pas du tout la même liste sur les deux versions. Je suppose ici que vous n'avez pas le problème signalé au début de ce post qui empêchait chez moi  cette manip sur graphedit32.

Par exemple, dès le début de la liste on voit que graphedit64 affiche par exemple un filtre AudioRecorder WAV Dest, que graphedit32 n'affiche pas. Au contraire graphedit32 présente un filtre ATi Ticker ou toute la série des Cyberlink que graphedit64 n'affiche pas.

On peut supposer que graphedit64 n'affiche que les filtres compatibles avec des applications 64 bits, alors que graphedit32 affiche les filtres compatibles avec des applications 32 bits. Un certain nombre de filtres sont naturellement compatibles avec les deux systèmes.

Quand je lance alors mon gestionnaire de filtres Filmerit 3.1, il m'affiche exactement les mêmes filtres que graphedit32. Cela paraît finalement normal, car toutes mes applications sont faites avec un delphi 7 qui est 32 bits. Elles sont donc toutes en 32 bits, et Filmerit du coup ne gère que les filtres 32 bits. Il faudra un jour voir comment s'occuper des filtres 64 bits. En attendant, mes programmes n'utilisent tous que des filtres 32 bits.

J'en reviens au problème de LAVideo.ax qui avait bloqué l'affichage de la liste des filtres directshow dans graphedit32. Il apparaît que c'est parce que l'un des pins disposait de plus de 100 types de formats. En fait, la version installée par Video to Video comportait exactement 218 types de formats pour le Pin 00. Ils sont numérotés de 0 à 207, puis s'ajoutent encore -39 à -48. Si on considère qu'un numéro négatif est en fait à retrancher à 256, on trouve que ces numéros négatifs vont de 208=256-48 à 217=256-39. Si on veut garder LAV Video installé, soit on le laisse comme il est, car il fonctionne correctement malgré tout sauf qu' on ne peut plus utiliser Graphedit32  pour construire des graphes. L'autre solution est sans doute d'enlever un certain nombre de types qui correspondent à des formats de vidéo rarement rencontrés. Mais cela nécessiterait un bidouillage à la main que je ne recommande pas.

Tout cela m'a quand même donné envie de voir comment les filtres sont enregistrés dans le registre de Windows 7 en 64 bits.

S'agissant des filtres directshow 32 bits, comme toutes les applications 32 bits, regedit les fait apparaître sous des clés WOW6432Node.

Un filtre directshow 32 bits apparaît ainsi dans le registre sous plusieurs emplacements:

HKEY_CLASSES_ROOT\Wow6432Node\CLSID\ est une clé où apparaît d'un part dans la sous-clé
{083863F1-70DE-11D0-BD40-00A0C911CE86}\Instance\ la liste des filtres 32 bits de la catégorie directshow , d'autre part comme une sous-clé  le GUID de chacun des filtres directshow 32 bits, et son fichier serveur sous la valeur InProcServer32.

La même chose se produit de façon dupliquée dans HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Wow6432Node\CLSID\

comme dans
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Classes\CLSID\

Un filtre directshow 64 bits apparaît pour sa part de la même façon (liste des GUID dans la catégorie des filtres directshow, et Inprocserver32) sous les clés plus simples: HKEY_CLASSES_ROOT\CLSID\ et HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\.

Enfin, si je prends un filtre qui est installé aussi bien pour 32 bits que 64 bits, par exemple avi mux, alors il apparaît en principe dans les 5 positions (et toujours deux fois dans chacune).

Il est à noter que dans delphi 7 qui ne sait lire que les fichiers 32 bits, tout cela est masqué, et qu'en croyant ouvrir la clé HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\ avec une fonction openkey on ouvre en réalité la clé HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Wow6432Node\CLSID\.

Pourquoi faire simple quand on peut faire compliqué !

Egaler le Player for AVCHD?

Le player for AVCHD dont je parlais dans mon précédent billet sait très bien lire aussi des vidéos HD qui se trouvent sur le disque dur. Pour en faire la démonstration, j'ai copié directement (via le couper coller de Windows) les dossiers AVCHD et AVF_INFO depuis la mémoire du caméscope (qui apparaît sous forme d'un périphérique amovible) vers la racine d'un de mes disques durs.

Lorsque je lance alors la commande Player for AVCHD, (via PMB Launcher, sous l'onglet Affichage), cette application lit la vidéo que je viens de recopier. La preuve en est que je peux débrancher le caméscope et que la lecture reste toujours possible. Elle est d'assez bonne qualité même sur mon ordinateur Pentium 4, aujourd'hui démodé, sous Windows XP SP3. Au passage, cela prouve que ce que je présumais dans un billet précédent est faux: il n'est pas nécessaire de faire l'hypothèse d'un traitement que subit la vidéo dans le caméscope. C'est forcément à la qualité intrinsèque du programme fourni par Sony que revient le mérite de cette relativement bonne lecture, bien meilleure en tout cas que ce que peut faite le lecteur Windows Media.

La question que je me pose, pour fabriquer des programmes nécessitant de lire des vidéos au format AVCHD, est de savoir si cette qualité est reproductible sous directshow, c'est-à-dire en composant un graphe avec des filtres appropriés et en le faisant jouer.

J'arrive assez facilement à reproduire le fonctionnement du lecteur Windows media, ce qui est sans surprise car ce dernier fonctionne sous directshow. Pour ce faire, j'ai pris soin d'installer sur mon système deux groupes de filtres directshow qui permettent de construire le graphe en question, à savoir Halli Media Splitter, qui est un filtre source combiné avec un splitter très bien adapté aux fichiers mts ou m2ts, et puis le fameux ffdshow qui permet dans ses versions récentes comme ffdshow-tryouts de décoder beaucoup de types de compression, dont le fameux MPEG-4 AVC utilisé dans la norme AVCHD.

On obtient alors le graphe très simple suivant (construit ici dans graphedit):


Ce graphe n'arrive pas bien loin chez moi puisque, exactement comme le lecteur Windows media, au bout de quelques secondes la vidéo se bloque et au mieux l'audio continue seul à jouer. Ce n'est donc manifestement pas comme cela que le Player for AVCHD fonctionne.

J'ai fait une petite découverte à ce propos (mais elle n'a peut-être rien à voir): avec PMB sont fournis toute une série de fichiers *.ax que l'on trouve chez moi dans le dossier d'installation, par exemple c:\Program Files\Sony\PMB et dans son sous-dossier TapeImporter.

Ces fichiers *.ax contiennent des filtres directshow, qui n'ont pas été installés sur mon système. A l'aide de mon utilitaire Filmerit, je les ai installés sur mon système et cela m'a donné 44 nouveaux filtres, tous classés dans la catégorie directshow, et - sauf pour trois d'entre eux - ayant un nom qui commence par Sony...

Pour être complet, les trois qui ne commencent pas par "Sony", s'appellent SGCtrl, Video Type Change et VMLib Filter. Je me demande si certains de ces filtres ne pourraient pas aider à former un graphe capable de lire aussi bien que Player for AVCHD.

En fait, rien n'est moins sûr, car ayant pris avec Filmerit une photo des filtres avant d'installer PMB et une autre après, il apparaît clairement que PMB n'installe aucune filtre directshow lors sur l'ordinateur. Donc soit il n'est pas basé sur la technologie de directshow, ce qui est probable vu qu'il n'est pas réservé à Windows mais doit aussi fonctionner avec Mac, soit il n'utilise que des filtres internes sans les installer dans le registre de Windows. Dans les deux cas, il sera difficile de reproduire le comportement de PMB ou de l'application Player for AVCHD.

CaptureFlux et les DVC 130 et 170

Le DVC 170 , comme d'ailleurs le DVC 130, sont des boîtiers de capture vidéo très peu chers, et qui compressent la vidéo par le hardware (donc sans mobiliser le processeur) en mpeg 1, 2, voire en mpeg-4 et divx. En France, il s'appellent Dazzle Video Creator ou Dazzle Video Creator Platinum, et sont en fait une marque de la société Pinnacle. Celle-ci les distribue avec ses logiciels (genre Studio), mais beaucoup d'utilisateurs regrettent de ne pas pouvoir utiliser d'autres logiciels, notamment pour voir la vidéo en plein écran , sans être obligé de l'enregistrer. C'est le cas de Gaël qui a commenté mon billet précédent. Mon logiciel CaptureFlux fait cela pour pas mal de systèmes, aussi suis-je souvent sollicité pour le rendre compatible avec ces boîtiers.

En fait, je n'ai jamais essayé aucun de ces deux boîtiers, mais je dispose d'un boîtier ADS Tech DVD Xpress DX2, qui utilise la même puce que les DVC 130 et DVC 170 pour numériser et compresser la vidéo. Il s'agit de l'excellente puce WIS GO7007SB, qui a pour les Français aussi l'avantage d'accepter des entrées vidéo en SECAM.

J'ai réussi à faire marcher CaptureFlux avec le boîtier ADS en réalisant un plug-in spécialisé. Grâce à plusieurs utilisateurs de DVC 170 qui ont fait des tests, j'ai aussi développé un plug-in pour les boîtiers Dazzle. Malheureusement cela ne semble pas marcher pour tout le monde, probablement parce qu'il y a plusieurs versions du driver de cette puce, et que mes plug-ins pour CaptureFlux ne marchent que pour certains d'entre eux.

Ce billet de mon blog s'adresse donc aux utilisateurs de DVC 170 et DVC 130 qui voudraient faire marcher CaptureFlux avec leur boîtier. S'ils veulent que je développe un plug-in pour eux, ils devront m'aider en faisant un certain nombre d'essais ou de tests, et en me donnant leurs résultats.

Pour cela, il faut savoir utiliser graphedit. J'ai une page web sur graphedit qui explique comment cela se fait. Si vous ne l'avez pas encore, téléchargez-le plutôt sur doom9 qui donne une version plus récente que Digital Digest (il faut chercher la full software page, puis la rubrique filters). Ne lancez pas tout de suite register.bat, car il installe un tas de filtres directshow dont vous n'aurez pas besoin en principe. La seule chose dont vous avez besoin c'est d'installer la dll qui permettra d'ouvrir les pages de propriétés. Elle s'appelle proppage.dll. Pour cela, soit vous éditez (avec notepad.exe) le fichier register.bat et effacez toutes les lignes sauf regsvr32 proppage.dll /s, soit vous utilisez mon logiciel Filmerit, et glissez simplement le fichier proppage.dll sur sa fenêtre.

Branchez maintenant votre boîtier. Par précaution, vérifiez avec le logiciel d'origine qu'il marche et donne une image. Mais ensuite quittez complètement le logiciel, tout en laissant le boîtier branché.

Lancez ensuite graphedit, puis lorsque la fenêtre vide est affichée, tapez CTRL+F. Chargez d'abord le filtre source de capture qui correspond à votre boîtier. Il doit se trouver dans la rubrique Video Capture Sources, et s'appelle chez moi ADS DVD XPRESS DX2. Chez vous, il y a des chances qu'il s'appelle Dazzle DVC170 ou encore Dazzle DVC 130. Peut-être allez-vous trouver encore autre chose. Sélectionnez-le et tapez Insert Filter.


Puis vous allez dans la rubrique Périphériques de distribution de flux WDM et essayez de trouver un filtre Crossbar. Chez moi, il s'appelle WIS GO7007SB Crossbar, mais chez vous il pourrait s'appeler Dazzle DVC170 CrossBar ou encore Dazzle DVC130 CrossBar, ou autre chose.
Insérez-le aussi.
Ensuite, il faut essayer de construire le graphe. La première chose à faire est de relier le filtre crossbar et le filtre source. Chez moi le filtre source n'a qu'une entrée. On la relie à la sortie vidéo du filtre crossbar. Peut-être chez vous en aura-t-il plusieurs? A vous d'essayer au mieux.

Ensuite, vous terminez le rendu du graphe en cliquant avec le bouton droit sur les broches de sortie du filtre source, et en choisissant render pin. Attention, s'il y a une broche de capture et une broche de preview, il vaut mieux pour mes essais rendre les deux. Souvent, il y a aussi une broche audio. Rendez-la itou.

Vous devriez alors obtenir un graphe complet, du genre suivant:

Avec un peu de chances, il marchera quand vous tapez Entrée pour le faire jouer. S'il ne donne qu'une image noire, il faut sans doute configurer la crossbar. Vous cliquez sur le filtre Crossbar avec le bouton droit, et affichez sa page de propriétés. La principale chose à faire est de vérifier la source vidéo: composite ou s-vidéo, selon ce qui est branché sur votre boîtier. Parfois il y a d'autres réglages. A vous de regarder.

Quand vous avez un graphe qui marche, et qui donne une image et du son, c'est presque gagné: vous pouvez déjà profiter de votre boîtier autrement qu'avec Studio de Pinnacle. Enregistrez le graphe avec CTRL+S, et envoyez-le moi (c'est un filtre grf) avec les commentaires utiles. Ce sera ma matière première pour fabriquer un plug-in.

A ce stade, il faut remarquer que le filtre source peut donner des flux vidéos très différents: mpeg1, mpeg2 ,mpeg4 ,divx etc... selon les règlages de sa page de propriétés. Chacun de ces flux sera rendu différemment, notamment en mobilisant un décodeur différent. Vous devriez donc recommencer plusieurs fois, et avant de rendre les broches de sortie du filtre source, ouvrir sa page de propriétés et choisir différents formats de sortie, puis compléter le graphe de rendu. Envoyez-moi tous les graphes obtenus qui marchent.
Il reste une dernière difficulté: CaptureFlux doit décomprimer l'image dans la mémoire vive de l'ordinateur, et pas dans la mémoire de la carte vidéo. C'est un problème qui se pose avec les flux mpeg2, qui sont parfois décodés en mode overlay. Si le graphe de rendu fait appel à des filtres décodeurs de mpeg2 tels que ceux de Cyberlink, et fait apparaître un filtre overlay ce n'est pas bon pour CaptureFlux. Il faudra donc voir si vous avez d'autres filtres mobilisables. Le mieux pour cela, est d'utiliser mon logiciel Filmerit, déjà cité plus haut pour prendre une photo de tous vos filtres, et de m'envoyer aussi le zip obtenu.

Pour l'envoi, vous trouverez mon adresse e-mail sur mon site, ou sur les pages d'aide de CaptureFlux ou Filmerit. Si ces indications ne sont pas claires, faites des commentaires à ce billet. Sinon envoyez-moi vos résultats.

Logiciels portables

Il y a une demande croissante pour des logiciels portables, c'est-à-dire des logiciels que l'on copie sur une clé USB ou sur un disque dur externe, et que l'on peut ensuite transporter avec soi et brancher à volonté sur n'importe quel système matériel.

L'idée est vraiment intéressante, car c'est exactement l'idée inverse de celle dont rêvent toutes les grandes firmes informatiques qui voudraient nous imposer des systèmes n'ayant plus d'unités de stockage, pour que tout soit stocké sur leurs serveurs centralisés, et que nous devenions totalement dépendants de leurs services et de leurs réseaux.

Le logiciel portable permet à l'inverse de ne plus dépendre du tout du matériel, qui ne devient qu'un hôte pour notre unité de stockage portable, tout ce qui est important étant décentralisé auprès de l'utilisateur.

La première condition pour qu'un logiciel soit portable, c'est qu'il n'ait pas besoin d'inscrire des données dans le registre de Windows. Certains disent qu'il ne doit pas avoir besoin d'installation. En réalité c'est seulement l'installation dans le registre de Windows ou dans des dossiers fixes du système comme c:\windows\system32 qui doit être prohibée. Si le logiciel a une procédure d'installation qui se contente de copier des fichiers sur l'unité de stockage portable, alors cela ne nuit pas à la portabilité. Par exemple, dézipper des fichiers. S'il écrivait par contre des données dans le registre de Windows, il ne pourrait pas les transporter sur un autre ordinateur, et ne pourrait ainsi sans doute pas fonctionner sur son nouvel hôte.

Vous savez que mes logiciels n'ont pas besoin d'installation, autre que de dézipper le fichier exécutable. Ils respectent donc le 1er niveau de portabilité. Mais ils sauvent - du moins si vous l'acceptez - leurs préférences dans le registre. D'où le second niveau de portabilité à respecter: pouvoir retrouver ses préférences quel que soit le système sur lequel tourne la clé. Par exemple si vous avez un navigateur web, vous voudrez avoir toujours sous la main ses favoris. Ou si vous avez changé les couleurs dans Filmerit, il faut que ces changements suivent le logiciel dans la clé usb.

J'avais tenu compte de cet objectif sur les dernières révisions de DVdate, Filmerit et ImageGrab, en permettant à l'utilisateur de sauver ses préférences dans un fichier ini situé dans le même dossier que l'application, donc circulant avec cette dernière sur l'unité de stockage mobile.

Christophe qui travaille sur le projet liberkey, une compilation de logiciels portables gratuits que l'on peut copier sur une clé usb, me signale que cela n'est pas encore suffisant.

En effet, dans les préférences, il y a parfois l'indication d'un dossier, ou d'un fichier utilisables par le logiciel. Par exemple dans DVdate, les préférences comprennent:

• le dossier par défaut pour ouvrir des vidéos
• le dossier préféré ouvert par F7
• le dossier par défaut pour ouvrir les playlist
• le dossier pour les fichiers créés par conversion
• l'emplacement du fichier imagegrab
• l'emplacement de deux fichiers à lancer par F3 ou F4

Enfin, de manière moins voyante, sous le nom exename, les préférences sauvent aussi l'adresse de l'application. C'est utile pour que mes programmes puissent s'appeler l'un l'autre, en sachant où chacun a été copié.

Supposons maintenant que le fichier imagegrab soit sur la même clé usb que DVdate, sous le chemin e:\image\imagegrab.exe. Ce fichier e:\image\imagegrab.exe sera noté dans le fichier ini. Or au prochain lancement, la clé sera peut-être implantée sur un autre ordinateur et aura hérité de la lettre de lecteur F:\. Alors DVdate aura un problème car il cherchera imagegrab.exe dans le dossier e:\image\ qui n'existe pas, et qui est devenu le dossier f:\image\.

Christophe me demande d'en tenir compte dans mes logiciels, en sauvant des chemins relatifs au lieu de sauver des chemins absolus. C'est ce qu'on pourrait appeler une précaution de troisième niveau.

Cela me pose deux difficultés: d'abord une difficulté de programmation, car pour saisir des chemins j'utilise des composants de delphi qui ne fonctionnent qu'en chemin absolu.

Ensuite une difficulté de fond: pour un logiciel qui traite de vidéo numérique, il faut manipuler de très gros fichiers. Il y a donc peu de chances que le dossier où chercher ces très gros fichiers soit sur une clé usb. En revanche, il pourrait très bien être sur un disque dur externe. Dans le premier cas, il est donc inutile de transcrire son adresse en relatif, alors que dans le second cas, il faudrait y procéder. Comment faire la différence?

J'ai mis au point la solution suivante pour contourner ces difficultés, et compte l'implanter dès la prochaine révision de mes logiciels:

D'abord l'utilisateur devra indiquer s'il veut que sa version soit portable (donc enregistre ses préférences dans un fichier ini situé dans le même dossier que l'application) ou s'il veut que sa version soit normale (et enregistre ses préférences dans le registre).

S'il est dans le premier cas, au prochain lancement, le programme regardera quelle était la lettre du périphérique dans l'exécutable indiqué sous exename. C'était la lettre de l'unité usb ou disque dur externe, par exemple E:\. Ensuite il regarde quelle est la lettre actuelle du périphérique sur lequel se trouve l'application (qui par définition est considéré comme une unité de stockage portable). Par exemple F:\.

Chaque fois que dans les préférences apparaîtra un dossier ou le chemin d'un fichier commençant par la première lettre ( E:\), on corrigera cette lettre en la remplaçant par la seconde ( F:\).

De cette manière, toutes les références qui pointaient vers la clé usb (ou le disque dur externe) continueront à pointer vers la clé usb (ou le disque dur externe). Pour autant, l'utilisateur n'a absolument besoin de se préoccuper de rien, il ne verra que des chemins absolus et non relatifs, et le programme n'écrira dans le fichier ini que des chemins absolus et non relatifs. C'est DVdate qui saura relativiser tout cela au lancement.

Si Christophe lit ce billet, il me dira peut-être qu'il faut assurer un quatrième niveau de portabilité: en effet, il ne lui aura pas échappé que DVdate peut sauver l'adresse d'une playlist. Avec ma technique de 3ème niveau, si l'utilisateur prend soin de sauver la playlist dans un dossier qui figure sur la clé usb, alors DVdate pointera toujours vers ce dossier, même si la clé a été déplacée sur un autre système. Par contre, le fichier playlist.txt ainsi pointé, liste lui-même des fichiers vidéo, dont certains pouvaient être sur la clé usb. Si j'étais rigoriste, je devrais donc aussi corriger ces fichiers en changeant leur périphérique E:\ en F:\.

Je ne suis sans doute pas assez rigoriste en matière de portabilité pour aller aussi loin, car au fond je crois que ce n'est pas utile, et compliquerait les opérations de DVdate. Par contre, si je trouvais un mécanisme simple et automatique pour imposer toutes les corrections de E:\ vers F:\au fur et à mesure que l'on veut utiliser un fichier ou un dossier, sans devoir les lister a priori, je n'hésiterai pas à l'implanter.

En attendant, vous pouvez tester la clé liberkey sur laquelle vous trouverez Filmerit, en version 3.0.8, donc avec une portabilité de niveau 2 pour reprendre l'échelle ci-dessus. Et ne ratez pas la prochaine version 6.4.0 de DVdate, qui devrait avoir la portabilité de niveau 3.

Si vous n'aimez pas regsvr32

Quand vous avec récupéré un filtre directshow, il se trouve souvent dans un fichier *.ax (ce que j'appelle le fichier serveur) qu'il faut alors installer sur votre système. La méthode classique suppose d'écrire avec notepad un fichier *.bat contenant une ligne de commande du genre:

regsvr32.exe c:\chemin\fichier.ax

Cela marche assez bien, mais n'est pas très commode à l'heure des interfaces graphiques de Windows (on se croirait encore sous DOS quand on travaille comme cela). De plus cela peut poser des problèmes si on ne sait pas écrire très exactement les chemins soit vers regsvr32.exe, soit vers le fichier serveur. (Quand il y a des espaces dans un nom de dossier, faut-il le mettre entre guillemets?)

Filmerit 3.0.0 comprend une petite fonction toute simple: il suffit de glisser/déposer le fichier serveur sur sa fenêtre, et votre filtre est installé.

Je me demande pourquoi cela n'avait pas été proposé plus tôt.

Filmerit 3.0.0 est en ligne

Je mets aujourd'hui en ligne la version beta 3.0.0 de Filmerit.


Elle m'a demandé quatre mois de travail. Elle représente un progrès très substantiel par rapport à la version 2.1 précédente. Jugez plutôt:

- Elle permet d'analyser quatre sortes de filtres à savoir les filtres directshow, les filtres DMO, les filtres Compression Manager, et les filtres Plug-and-Play. Elle peut même afficher les filtres plug-and-play inactifs, par exemple si vous aviez un jour branché un camescope DV sur votre ordinateur, il restera un filtre PnP inactif appelé "Microsoft DV Camera and VCR".

- La liste des filtres peut être affichée triée soit selon l'ordre des catégories, soit selon l'ordre alphabétique, soit selon les valeurs des mérites (ce qui est commode pour repérer tout de suite les filtres qui s'imposent avec de grosses valeurs), soit selon le fichier serveur.

- La liste des filtres (avec toutes leurs caractéristiques) peut être sauvée dans des fichiers comprimés zip, contenant soit un fichier de texte pur, soit un fichier rtf avec des mises en forme pour en faciliter la lecture.

- Pour augmenter la sécurité, Filmerit essaie de créer un point de restauration avant de sortir du mode "Lecture seule".

- Un support (minimaliste, certes) pour Windows Vista est assuré. Il faut savoir que Vista protège très rigoureusement l'accès aux clés de registre. Il faudra donc, si vous utilisez vista, soit lancer l'application comme administrateur, soit même désactiver le "User Account Control", avant de quitter le mode "Lecture seule".

- Une amélioration pour tous ceux qui aspirent à des programmes "portables", c'est-à-dire qu'on peut lancer depuis une clé usb, sans qu'elle ne modifie le registre: on peut maintenant sauver les préférences de Filmerit dans des fichiers ini si on veut.

-La fenêtre de Filmerit peut être redimensionnée, voire mise en plein écran, pour améliorer le confort de travail.

Et bien sûr, les fonctions de base de Filmerit restent plus que jamais présentes:

• lister et analyser les filtres présents sur un système
• comparer les filtres avant et après une installation
  
• effacer des filtres
• réparer des filtres
• modifier le mérite d'un filtre
• recharger toute une configuration de mérites
• réparer d'un seul bouton tout le système
  

Attention, cependant cette version 3.0.0 doit être considérée comme une version beta. Elle pourrait encore subir quelques corrections dans les semaines qui viennent. Je serai très reconnaissant à ceux qui accepteront de la tester et de me faire part de leur expérience.

Pour la télécharger, il faut cliquer ici

Codecs ou filtres?

Il y a beaucoup de confusion dans les forums Internet sur les codecs et les filtres. Essayons de clarifier cela un peu.

Ce qui est commun aux deux concepts, c'est l'idée d'avoir un fichier spécialisé contenant un algorithme de compression ou de décompression, de façon à ce que toutes sortes d'application multimedia puissent l'utiliser. Ces applications lorsqu'elles ont besoin de faire le traitement dont il s'agit, chargent le fichier en mémoire et appellent certaines des fonctions qui y sont contenues. Par exemple comprimer une vidéo en XviD MPEG-4 Codec fait appel à un fichier xvidvfw.dll ou comprimer en DivX s'appuie chez moi sur un filtre DivX Encoder Filter contenu dans un fichier divxenc.ax.

Microsoft a défini deux "architectures" différentes pour créer des applications multimedia. La plus ancienne s'appelle Video for Windows (vfw), la plus récente s'appelle directshow. La manière de rechercher et d'appeler les fichiers de compression ou décompression est différente selon l'architecture, ce qui crée une différenciation entre les fichiers destinés à une application vfw ("les codecs") et les fichiers destinés à une application directshow ('les filtres").

Un exemple d'application video for windows est virtualdub. Un exemple d'application directshow est Windows Media Player, mais aussi mes applications CaptureFlux ou ImageGrab.

Heureusement, Microsoft a prévu une compatibilité ascendante: les codecs VFW existant sur le marché peuvent dans la plupart des cas être utilisés par une application directshow, grâce au Video Compression Manager. C'est un filtre directshow générique, contenu dans un fichier qcap.dll, qui au lieu d'effectuer lui-même un traitement, sait appeler un ancien codec VFW à qui il sous-traite le travail. C'est donc grâce à lui que les codecs peuvent être utilisés dans les applications directshow, sans devoir être réécrits spécialement.

Mais cette compatibilité ne marche que dans un sens. Dans l'autre sens, il y a beaucoup de filtres de compression ou de décompression qui ne peuvent être utilisés que par des applications directshow, et qui sont inexploitables par une application VFW. C'est notamment le cas des filtres Microsoft de compression ou décompression DV (qui s'appellent parfois improprement les codecs DV ou dvsd de Microsoft), qui n'existent que sous forme de filtre, ce qui fait que VirtualDub a du mal avec les fichiers DV, sauf si vous installez un codec DV comme celui de Mainconcept ou de Panasonic.

Pour reprendre l'exemple cité plus haut, XviD MPEG-4 Codec est bien un codec VFW, qui grâce au compression manager peut aussi être utilisé dans une application directshow. CaptureFlux sait par exemple le mobiliser pour faire de la compression en Xvid en temps réel. A l'inverse, DivX Encoder Filter est un filtre directshow, qui n'a pas la capacité d'être exploité par une application VFW.

Ce qui est vrai pour la vidéo l'est aussi pour l'audio. Il faut distinguer entre les codecs audio et les filtres directshow traitant l'audio. Grâce à l' Audio Compression Manager, contenu dans le fichier quartz.dll, il y a la même compatibilité ascendante. Par exemple un codec de compression en mp3 est fourni en standard dans le fichier l3codeca.acm. Un filtre pur de compression en mp3 est contenu dans le fichier lame.ax qu'on peut télécharger sur le site Elecard.

Dans sa version 2.1, Filmerit ne traitait que des "purs filtres directshow", et n'indiquait rien sur les codecs. Dans sa version 3.3, Filmerit traitera aussi les filtres construits à partir des codecs video ou audio.

Pourquoi un blog de Paul Glagla

Je suis l'auteur de quelques logiciels principalement dédiés à la vidéo numérique, notamment DVdate, CaptureFlux, ImageGrab et autres Filmerit ou CassetteDV qui connaissent un joli succès à la fois en France et dans le reste du monde.

Jusqu'à présent, je communiquais avec mes utilisateurs, d'une part avec mes pages web, et d'autre part par e-mail.

Mais produire des pages web est un boulot lourd et peu réactif, qui m'est très pénible, et me prend beaucoup de temps que je préfère consacrer à de la programmation.

D'un autre côté, le problème des e-mails, c'est que je reçois des dizaines de messages (sans même parler du spam) qui portent sur des tas de sujets souvent intéressants mais très spécifiques et que chaque réponse nécessite de ma part des réflexions et des recherches qui au bout du compte ne bénéficient qu'à un seul utilisateur. Du coup, je m'y investis moins. Actuellement je réponds à moins de 5% des mails que je reçois. Par contre, je lis tous les mails reçus et je finis tôt ou tard par exploiter les idées qui me sont soumises. Ce n'est donc pas inutile de continuer à m'écrire.

Devant cette situation, j'ai pensé me mettre au goût du jour et créer un blog, pour compléter mon site et mes e-mails par des communications diverses, mais d'intérêt général pour les amateurs de mes logiciels. Cela me permettra de diffuser des idées ou des commentaires et de susciter une certaine interactivité, sans efforts trop démesurés.

J'espère bien sûr avoir des réponses sur les sujets que je lancerai. C'est vital pour que mes productions progressent, car je n'ai accès qu'à très peu de matériel ou de logiciels. Je suis en effet un simple amateur dont l'équipement se limite en ce moment à

- un ordinateur Pentium4 à 3GHZ avec 512 M0 de mémoire, muni de Windows XP SP2
- un camescope Sony DCR-PC101E Pal, donc un modèle déjà assez ancien
- une webcam Logitech Clicksmart 310
- un boitier ADS Tech DVD Xpress DX2
- une ancienne carte miro DC30+

C'est avec ce matériel que je teste mes productions. Cela ne couvre donc qu'un petit champ des configurations que l'on rencontre sur le marché. D'où mon slogan: "mes logiciels fonctionnent bien chez moi, ils pourraient bien fonctionner chez vous, mais peut-être pas. Essayez vous-même, et faites moi savoir ce que cela donne."

Encore une chose: je travaille par périodes sur un programme donné. Actuellement c'est sur Filmerit. Si vous me donnez des idées ou des constatations qui concernent le programme sur lequel je suis en train de travailler, je les exploiterai beaucoup plus vite. Les autres commentaires seront stockés et vraiment utiles peut-être seulement dans quelques mois.

Pour vous permettre de cibler vos remarques, voici le planning que j'envisage pour les prochaines semaines:

D'abord terminer une version 3.0.0 de Filmerit. L'objectif principal est d'étendre ce logiciel à l'analyse et à la réparation des filtres directshow de toutes catégories. Actuellement, il ne s'occupe que des filtres qui sont en directshow natif. A l'avenir, il devrait aussi s'occuper des filtres DMO (Direct Media Object), des filtres Compression Manager, et des filtres Plug and Play. Cela devrait encore me prendre le mois d'avril.

En mai, j'ai envie de réattaquer ImageGrab qui est actuellement resté à la version 3.0 depuis juillet 2004. J'ai de nombreuses idées pour le mettre à jour, ne serait-ce qu'en y intégrant des technologies qui sont maintenant couramment intégrées dans mes logiciels plus récents: par exemple sauvegarder les préférences dans le registre, désentrelacer les images sans utiliser Studio, y incruster du texte ou une date, retourner l'image en miroir etc... Peut-être encore d'autres nouveautés.

Ensuite, cet été, je compte bien revoir CassetteDV. C'est l'un des logiciels dont je suis le plus fier, mais je vois bien qu'il crée de nombreux déçus. Il est en effet très complexe, et dépend beaucoup de chaque configuration. Il y a à l'évidence des configurations avec lesquelles il ne fonctionne pas bien, et ce sera donc l'objectif principal de la prochaine grande révision à venir que d'améliorer sa compatibilité avec davantage de situations.

Entre temps, il n'est pas exclu que je publie des versions de CaptureFlux ou DVdate corrigeant certains bugs. La version 6.3.0 de DVdate est d'ailleurs en phase de test. Si vous voulez la tester, elle est téléchargeable ici. Elle corrige quelques bugs (j'espère qu'elle n'en crée pas d'autres ce faisant !?) et apporte une petite amélioration fonctionnelle: l'incrustation peut maintenant être entourée d'un bordure noire pour que le texte incrusté ressorte mieux devant la vidéo, même quand le fond est clair.