Bientôt la version 7.0 de DVdate

J'ai un peu négligé mon blog depuis quelques semaines, et déçu beaucoup de correspondants en ne répondant pas à leurs mails. Ce n'était pas par paresse, mais parce que je consacrais tout mon temps libre à travailler sur la version 7.0 de DVdate. C'est une version totalement réécrite pour améliorer certains aspects importants.

Parmi les nouveautés qui feront sûrement son succès on peut signaler les éléments suivants:

• tout le programme est maintenant compatible avec les caractères Unicode. Cela permettra à nos amis asiatiques d'apprécier pleinement DVdate en voyant leurs noms de fichiers écrits avec les caractères de leur langue asiatique.

• tout le travail sur les scènes est considérablement développé. Beaucoup apprécieront notamment de pouvoir exporter les scènes non seulement dans un fichier texte, mais aussi dans un fichier Excel, dans un tableur OpenOffice.org ou aussi, dans un document Word ou OpenOffice.org/Writer. Pour ces deux derniers cas, le document exporté comprend une image par scène. Voici un petit aperçu de document ainsi obtenu, idéal pour faire une table d'archivage des scènes. Il s'agit de la vidéo de Jimi Hendrick à Woodstock, découpée en scènes de 30 secondes. On peut télécharger ici le document OpenOffice.org en entier. Attention, je ne diffuse pas de vidéo!
  

• un éditeur de l'incrustation très puissant permet de modifier à volonté la police, la position et le type d'incrustation tout en faisant jouer une vidéo (et sans allers-retours avec le panneau des préférences). On peut maintenant incruster le datecode, le timecode et aussi n'importe quel texte sur 2 lignes, ou toute combinaison.

• Le programme n'est plus enfermé dans une fenêtre de taille fixe. On peut ajuster sa taille, jusqu'au plein écran, et profiter alors d'une vidéo agrandie et d'une liste des fichiers vidéos plus longue. On peut d'ailleurs basculer cette dernière de droite à gauche.
  

• Parmi les fonctions de conversion on a ajouté la conversion d'une vidéo DV de 16x9 en 4x3 et réciproquement.

Enormément d'autres améliorations ont été apportées, pour clarifier, perfectionner, sécuriser certaines commandes, ou les rendre plus "user-friendly".

A ce stade, le programme est déjà très opérationnel, mais doit encore recevoir des finitions et des tests. Il n'est pas non plus traduit en Anglais. Je le mets en téléchargement pour ceux qui voudraient l'essayer, tester en avant-première les nouveautés et me faire part de leur expérience. Comprenez bien que c'est une version beta et sans engagement, mais qui devrait déjà vous apporter des satisfactions très prometteuses. Ce blog pourrait être le bon lieu pour faire vos commentaires éventuels sur cette version. Ils me permettront d'accélérer sa finalisation.

>>> La version 7.0.0 de DVdate est à télécharger ici.

Conversion de Pal en NTSC

Jacques m'interroge - dans un commentaire à mon billet précédent - sur la conversion de DVD Pal en NTSC. C'est un sujet qui intéresse beaucoup de vidéastes si on en juge par le nombre de forums de discussions, de faq et de tutorials qui traitent de cette question.

Sur l'un des principaux sites américains qui traitent de DVD, videohelp.com, si je fais une recherche avec les deux mots-clés Pal et Ntsc, il cite 12.700 pages sur ce seul site qui contiennent ces deux termes, et publie 11 guides relatifs à cette question. On y trouve pêle-même la méthode utilisant l'application Cinema Craft Encoder (si vous avez $2000 à mettre dans un encodeur mpeg2) et celle qui utilise TmpgEnc (encodeur dont on peut avoir une version d'essai pour quelques cacahuètes), une méthode dite du patch qui ne nécessite aucune reconversion si on arrive à tromper son lecteur, comme une méthode dite en 12 étapes, qui semble une vraie usine à gaz.

Pour sa part, DVdate est très utile pour convertir de l'avi DV Pal en avi DV NTSC, et permet donc de faire un DVD NTSC à partir d'un camescope DV Pal, comme je l'explique ici. Mais j'ai bien peur que cela ne réponde pas au problème de Jacques, car il veut convertir les fichiers Vob de son DVD Pal et non des vidéos au format avi DV Pal.

Il n'est toutefois pas impossible d'obtenir quelque chose, mais ce serait assez lourd et se ferait avec une notable perte de qualité.

Pour ceux qui veulent vraiment tenter l'affaire, la méthode serait la suivante:

1. ripper le DVD en un avi divx de la meilleure qualité possible. Il existe plein de tutoriels un peu partout pour expliquer comment faire cela. Comme les divx peuvent être regardés sur l'ordinateur ou sur un nombre croissant de lecteurs DVD, on pourra d'ailleurs souvent s'arrêter là.
2. si on veut absolument obtenir un DVD NTSC, utiliser DVdate pour convertir le divx en une vidéo DV type 2 . C'est une commande du menu convertir, qui certes dégradera la qualité, mais pas beaucoup plus que le passage du vob en divx. On prendra soin dans les préférences de DVdate, de demander que cette conversion soit faite au format NTSC, et éventuellement à la fréquence audio 48000 Hz.
   
3. avec n'importe quel logiciel de montage vidéo capable de sortir un DVD (par exemple Studio de Pinnacle, ou Ulead, ou Nero), on charge alors le fichier avi DV NTSC fabriqué par DVdate et l'application produit en principe un DVD NTSC.

Cette méthode n'est évidemment pas très recommandable car elle a beaucoup d'inconvénients:

• D'abord, on multiple les décompressions/ recompressions: on doit d'abord décomprimer le vob pour le comprimer en divx, pour décomprimer le divx pour le convertir en avi DV NTSC, puis décomprimer le DV pour le reconvertir en vob (mpeg2). Cela fait une perte de temps et de qualité d'image. Les meilleures méthodes décompriment le vob initial et le compriment tout de suite en vob final: 1 seule décompression/recompression au lieu de 3.

• Ensuite on perd l'entrelacement: en principe le DVD initial était entrelacé pour une lecture fluide sur la TV. Il y a fort à parier que dans ces décompressions/recompressions l'entrelacement aura disparu. Or perdre l'entrelacement donne une image moins fluide sur la TV où le résultat final sera regardé. Paradoxalement, il faut d'ailleurs souhaiter qu'à l'une des étapes ci-dessus, et notamment la première, il y ait eu un désentrelacement propre des images, car sinon il y a fort à parier que le résultat final donnerait des stries d'entrelacement incontrôlées qui feraient un effet de peigne monstrueux sur l'image finale.

• Ensuite - et c'est le point faible de toutes les méthodes, quel que soit le prix que vous y mettrez -, il n'existe pas de bonne méthode pour passer de 25 images à 29.97 par secondes (on peut même arrondir à 30 si vous préférez, cela ne change rien). Aucune méthode du commerce ne se risque vraiment à fabriquer de nouvelles images en interpolant entre plusieurs images de la vidéo d'origine. En fait, elles prennent en substance dans la vidéo d'origine 5 images puis répètent la 5ème une fois pour former la 6 ème image. C'est ainsi que les 25 images (soit 5 groupes de 5) d'une seconde passent à 30 images (soit 5 groupes de 6).

Pour illustrer l'effet de ce bidouillage d'images, supposons que nous filmions une voiture qui avance sur une ligne droite à 90km/h , soit 25 m par secondes. Notre film d'origine qui est à 25 images/secondes la photographiera donc à la position 1 m, 2m, 3m.... jusqu'à 25m pour les images de la première seconde. Quand on aura converti cela en NTSC on aura une vidéo qui la montre à 1m sur la 1ère image, alors que le temps écoulé n'est que de 1/30ème de seconde et que la voiture devrait être à 25/30 m=0.83m. Puis la 2ème image à 2m, alors que la voiture est réellement au bout de 2/30 de secondes à 1.66m et ainsi de suite jusqu'à la 5 ème image qui présentera la voiture à la position 5 m, alors que le temps passé sera de 5/30èmes de secondes et donc que la position réelle devrait être de 4.17 m. Puis tout à coup se répète la position 5m pendant la 6ème image. Cela donne au total une vidéo qui semble un peu accélérée pendant 5 images (les 4,17 premières secondes de chaque séquence) puis s'arrête pendant une image, avant de recommencer le cycle.

Considéré autrement, on devrait voir chaque position sur l'écran de la voiture 1m, 2m, 3 m... 5m pendant 40 millisecondes. Après conversion, on voit la voiture à 1m, 2m jusqu'à 4m pendant 33 millisecondes chacune, puis on la voit à 5m pendant 66 millisecondes.

Cet effet ne me paraît pas totalement rédhibitoire, grâce à la bonne volonté de l'oeil humain. D'ailleurs la vidéo d'origine fait aussi des approximations, puisqu'elle montre la voiture faisant des sauts de 1 m par 1m, alors qu'elle avance en réalité continuement. Mais le processus donne quand même une impression légèrement saccadée et peu naturelle lorsqu'on regarde le résultat.

• Un dernier point faible, commun à toutes les méthodes: tout cela permet éventuellement de convertir un fichier vob issu du DVD, mais qu'en est-il des menus, sous-titres de langue, bandes audio additionnelles etc... C'est encore une autre paire de manches que de reproduire tout ce binz en gardant en outre toute la synchronisation nécessaire.
  

Plusieurs de ces inconvénients, sauf sans doute le premier, sont des points communs à la plupart des méthodes. C'est sans doute pourquoi aucune méthode n'a réussi à s'imposer. En fonction de ses besoins, et surtout de ses possibilités, notamment en disponibilité de logiciels, on pourra donc essayer diverses méthodes disponibles, quitte à savoir fermer les yeux sur leurs points faibles.

Retour de vacances

Me voilà rentré de vacances, avec 5 cassettes DV en LP de films à monter. Cela va concurrencer mes activités de programmation.



Ce qui me frappe en étant allé dans les pays les plus pauvres de l'Indochine, c'est qu'au moins dans leurs villes les cyber-cafés sont omniprésents et qu'il est très facile et peu cher de se connecter sur Internet et donc de suivre -même au bout du monde- ce qui se passe sur son blog, son site, ses messageries... On a là vraiment le sentiment concret que la mondialisation est en marche, et pas seulement dans quelques hôtels qui diffusent CNN.

Le vrai exotisme qui reste alors sur la planète est peut-être tout proche de nous: m'étant lamentablement perdu en voiture du côté de Deuil-la-Barre dans la banlieue parisienne l'autre soir, je me suis décidé à acheter mon premier GPS (un ViaMichelin X980T quand même!) pour pouvoir à l'avenir m'y repérer.

J'avais publié DVdate 6.4.1 avant mon départ. A mon retour je trouve plusieurs mails signalant des bugs qu'il fallait corriger d'urgence. J'ai donc fait immédiatement la mise à jour vers 6.4.4 publiée hier. J'en ai profité pour actualiser les pages d'aide sur mon site.

Il semble que CaptureFlux donne aussi quelques soucis à certains. Je vais voir si c'est remédiable rapidement, ou si cela nécessite une grande révision. Dans le premier cas, je le mettrai à jour tout de suite. Dans le second cas, je reporterai ces travaux jusqu'à ce que la grande révision de CassetteDV ait été faite.

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.

L'été sera glagla

Je trouve dans Libération un article qui ne peut pas me laisser indifférent, puisqu'il dit:

depuis que Nicolas Sarkozy est à l’Elysée, la météo est pourrie. Vents déments, pluies battantes, froid de gueux, nous n’aurons qu’un mot : glagla

Et l'article de décliner les programmes télé de l'été autour du thème glagla: Glagla, les miquettes; Glagla, les énigmes; Glagla, l'amour.

C'est pour moi l'occasion de vous confirmer mon programme de travail pour l'été 2007:

Je termine en ce moment une révision de DVdate,

Ce sera probablement la version 6.4.0, qui comprendra un vrai éditeur de scènes, capable de faire automatiquement la liste des scènes (par analyse du contenu s'il ne s'agit pas d'un programme avi DV), qui permettra ensuite de corriger ce découpage, en fusionnant ou découpant des scènes, de donner des titres aux scènes, et de sauver tout cela dans un fichier scn compatible avec Studio de Pinnacle, ou dans un fichier texte utilisable dans Excel ou tout autre programme pouvant importer des bases de données sous forme de texte séparé par des virgules.

J'espère terminer cela avant de partir en congés le 14 Juillet.

A mon retour, début août, c'est promis, je me lancerai dans la grande révision de CassetteDV que beaucoup de mes interlocuteurs attendent.

J'ai toujours beaucoup de demandes d'améliorations ponctuelles qui m'arrivent par mail pour chacun des programmes. Si elles ne concernent pas le programme sur lequel je suis en train de travailler, je les stocke jusqu'au moment où je lancerai la révision.

Mais le moment venu, il faut bien sûr trier parmi toutes les suggestions. Je sais que le côté usine à gaz des programmes rebute plus d'utilisateurs qu'il n'en satisfait. Donc j'y vais avec prudence, et n'essaie d'intégrer que des améliorations utiles au plus grand nombre et qui restent cohérentes avec l'esprit du programme.

Comment réviser ImageGrab?

ImageGrab est l'un des plus grands succès parmi mes logiciels. Si je tape ce mot-clé dans Google, je trouve 11.400 pages web qui l'évoquent. En France, CaptureFlux a plus de succès; dans le reste du monde, DVdate a plus de succès; mais dans les deux cas, ImageGrab vient tout de suite en second, si bien que, quand je globalise, ImageGrab est sans doute le logiciel de Paul Glagla le plus téléchargé et utilisé au monde.

Je me suis parfois demandé ce qui fait le succès d'ImageGrab: si quelques passionnés l'utilisent pour des activités fort sympathiques comme étudier la vie des chauve-souris, ou analyser des séquences sportives (notamment en parachutisme), une bonne partie des utilisateurs (dont moi-même) l'utilisent principalement pour extraire des images de vidéos destinées à illustrer des pochettes de DVD ou de CD. Mais je ne me fais pas d'illusion, au fur et à mesure que je découvre de nouveaux sites ou forums qui parlent d'ImageGrab, je me rends compte qu'il y a de plus en plus de sites pornographiques qui l'utilisent pour extraire des photos à partir de vidéo X. C'est pourquoi je m'en étais un peu désintéressé depuis juillet 2004, date de sa dernière révision.

D'un autre côté, je reçois tellement de remerciements pour ce programme au fond tout simple, que je me suis décidé à le réviser maintenant, ne serait-ce que pour y introduire quelques perfectionnements qui sont dans la plupart de mes autres programmes, et qui n'avaient pas encore été introduits dans ImageGrab.

J'ouvre donc la discussion sur mon blog: quelles améliorations faut-il apporter à ImageGrab?

Il y en a quelques-unes qui sont déjà prévues:

• permettre de sauver ses préférences, pour les retrouver au prochain lancement sans devoir tout reparamétrer.
• permettre une numérotation plus ouverte: certains utilisateurs se plaignent d'être contraints de numéroter les images avec 4 chiffres seulement
• ajouter et rationaliser les raccourcis clavier
  
• ajouter une fonction intégrée de désentrelacement des images, pour ne pas dépendre du filtre de désentrelacement de Pinnacle
• mieux gérer les vidéos en mpeg2 (si j'y arrive)
• permettre d'inverser l'image

Si vous avez d'autres attentes, c'est le moment de réagir sur mon blog.

Les fichiers scn

Un internaute hongrois me demande quelle est la structure des fichiers *.scn.

Rappelons que les fichiers *.scn sont produits par Studio de Pinnacle et contiennent les informations relatives au découpage en scènes d'un fichier vidéo. Pinnacle ne donne guère d'indications sur la structure de ces fichiers. Donc c'est en procédant à des expérimentations que j'ai pu comprendre un certain nombre des choses que je présente ici sans garanties.

J'ai implanté l'utilisation des fichiers *.scn dans ImageGrab et dans DVdate. En outre, DVdate comme CaptureFlux peuvent créer des fichiers *.scn à partir de vidéos au format DV.

En fait, ces fichiers sont inutilement complexes et redondants. Je suppose que Pinnacle les a introduits en se basant sur les fichiers de projet *.stu qu'utilise Studio. On aurait pu créer des fichiers plus simples contenant les mêmes données. C'est donc seulement parce que j'ai souhaité une compatibilité avec Studio que j'ai travaillé sur ces fichiers *.scn.

Un fichier *.scn commence par un en-tête qui en hexadécimal est le suivant:

63 26
01 00 04 00 00 00 FF FF
03 00 0A 00 'SourceTape' [len] filename 00 00 00 00 00 00 00 00 {nbscenes} FF FF
01 00 04 00 'Clip' 50 00 00 00 FF FF

Puis pour la première scène:

01 00 05 00 'Scene' 00 00 00 00 00 (scene_2) 00 00 00 00 01 80 [len] filename 00 00 00 00 00 00 00 00 (scene_2)

Puis pour chacune des scènes suivantes, notées scene_i (avec i>=2):

03 80 F0 00 00 00 05 80 00 (scene_i) (longueur_i) 00 00 00 00 07 00 (scene_i) (longueur_i) (scene_i)

Ici ma notation est la suivante:

• [len] est la longueur du nom du fichier avi (avec son chemin complet). [len] est noté sur un seul octet.
• filename est le nom du fichier avi avec son chemin complet
• {nbscenes} est le nombre total de scènes - sur 2 octets
  
• (scene_i) est le numéro de la frame dans le fichier avi où commence la scène i. scene_1 n'est ici pas utilisé, car il serait nul. Ce numéro est un entier codé sur 4 octets.
  
• (longueur_i) est la longueur - en nombre de frames -sur 4 octets de la scène i. Donc en principe (longueur_i)=(scene_i+1)-(scene_i)

Voilà c'est un peu bizarre, mais ce n'est pas moi qui ai inventé cela. En outre, je ne garantis pas que tous les fichiers *.scn suivent strictement ce format-là. Mais les fichiers que Studio a produit chez moi le suivent, et quand DVdate produit des fichiers *.scn de ce format, ils marchent dans Studio. Alors cela doit quand même être correct.

Paul Glagla censuré en Chine?

Jusqu'en décembre 2006, j'ai eu pas mal de visiteurs chinois sur mon site. J'ai entretenu une correspondance par e-mail avec certains d'entre eux, et notamment adapté DVdate aux caractères unicode pour pouvoir afficher du texte en Chinois. Pendant l'année 2006, la fréquentation moyenne de mon site à partir de la Chine a dépassé 10 visiteurs par jour.

Voici par exemple les statistiques de visites pour le 3ème trimestre 2006. On voit clairement un flux continu de visites, qui se situe entre 5 et 10 par jours.

Brutalement, depuis le 4 décembre, presque plus rien.

Voici les statistiques du 4ème trimestre 2006. On voit que le même flux se poursuit jusqu'au 3 décembre, et brutalement le 4 décembre le trafic tombe à 0, excepté très épisodiquement une seule visite.

Pendant tout le mois de janvier 2007, il y a en tout et pour tout seulement deux visites. Depuis février cela remonte doucement, mais sans réatteindre les fréquences d'avant 2006.

Pendant le 1er trimestre 2007, le trafic est nul en janvier, et reprend progressivement depuis le début février, mais avec des flux de 1 à 6 visites en pointe. (attention, ce graphique n'est pas à la même échelle que les précédents).

Je soumets à votre réflexion ces constatations. Sachant ce qu'on sait sur le contrôle d'Internet par les autorités chinoises, on peut tout imaginer. Mais franchement, je me demande ce qui peut paraître subversif sur mon site.

Comment reconnaître un fichier DV?

J'ai trouvé ces jours-ci sur le forum du site web VideoHelp une discussion à propos de DVDate. La question était in fine de savoir comment DVDate reconnaîssait qu'un fichier avi est un fichier DV.

Le moyen traditionnel d'identifier la compression d'un fichier AVI est de lire le code à quatre caractères (le "FourCC") qui apparaît dans l'en-tête. Cette méthode se heurte cependant à deux difficultés:

• d'une part, il y a plusieurs FourCC possibles pour un fichier DV: dvsd, dsvd ou par exemple CDVC pour le codec DV de Canopus. Il y en a encore d'autres, sans compter les variantes en majuscules.
  

• d'autre part, il y a plusieurs endroits où ce FourCC peut se lire, soit dans le AVI Stream Header, dans une variable appelée FourccHandler, soit dans le Stream Format Header, dans une variable appelée bicompression.

Si vous voulez voir ces valeurs pour un fichier avi donné, ouvrez celui-ci dans DVDate et tapez CTRL+H. Vous obtenez alors un listing, dont j'ai extrait à titre d'illustration les éléments intéressants:

---------------(Vidéo)---------------
------Début du AVI Stream Header------
FourccType = vids
FourccHandler = dvsd
Flags = 00000000
Priority = 0
Language = 0000
InitialFrames = 0
Scale = 400000
Rate = 10000000
Start = 0
Length = 29
SuggestedBufferSize = 144008
Quality = 00000000
SampleSize = 0
rcFrame.Left = 0
rcFrame.Top = 0
rcFrame.Right = 720
rcFrame.Bottom = 576
-------Fin du AVI Stream Header-------

et

----Début du Stream Format Header----
biSize = 40
biWidth = 720
biHeight = 576
biPlanes = 1
biBitCount = 24
biCompression = dvsd
biSizeImage = 144000
biXPelsPerMeter = 0
biYPelsPerMeter = 0
biClrUsed = 0
biClrImportant = 0
-------Fin du AVI Stream Format-------

Le problème était donc que certaines applications créent des fichiers avi où ces deux valeurs ne coïncident pas. Cela semble être le cas des fichiers DV produits par Adobe Premiere Pro 2, où la première valeur est vide alors que la seconde est "dvsd" (si j'en crois les constatations de JohnnyMalaria). Et dans ce cas la version 6.2.1 de DVDate ne savait pas trancher.

Il faut noter qu'avec ma webcam Logitech et mon freeware CaptureFlux, je crée des fichiers avi (certes pas DV) qui ont aussi ce problème, mais en sens inverse: c'est le FourccHandler qui est égal à "DIB ", alors que le paramètre bicompression ne comprend rien d'affichable.

------Début du AVI Stream Header------
FourccType = vids
FourccHandler = DIB
Flags = 00000000
Priority = 0
Language = 0000
InitialFrames = 0
Scale = 333333
Rate = 10000000
Start = 0
Length = 9
SuggestedBufferSize = 304136
Quality = 00000000
SampleSize = 0
rcFrame.Left = 0
rcFrame.Top = 0
rcFrame.Right = 0
rcFrame.Bottom = 0
-------Fin du AVI Stream Header-------

et

----Début du Stream Format Header----
biSize = 40
biWidth = 352
biHeight = 288
biPlanes = 1
biBitCount = 24
biCompression =
biSizeImage = 304128
biXPelsPerMeter = 0
biYPelsPerMeter = 0
biClrUsed = 0
biClrImportant = 0
-------Fin du AVI Stream Format-------

J'ouvre donc le concours: quelles sont les applications qui produisent des fichiers où ces deux paramètres sont distincts, et dans quelles conditions? Si vous en trouvez, postez nous ici le Header obtenu avec DVdate.

Dans la version 6.3.0 de DVDate, encore en phase de test, mais téléchargeable ici, j'ai pris l'option suivante: le codec est pris dans bicompression, sauf si cette dernière valeur contient des caractères non affichables (de valeur ASCII inférieure à 32). Dans ce cas, le codec affiché par DVDate sera la valeur FourccHandler.

Je me demande cependant si cela répond à tous les cas de figure. Ne faut-il pas faire l'inverse, et donner la priorité au FourccHandler?

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.