Affichage des articles dont le libellé est studio. Afficher tous les articles
Affichage des articles dont le libellé est studio. Afficher tous les articles

dimanche 25 janvier 2009

Retour sur les fichiers scn

En avril 2007 j'ai donné dans ce blog les informations dont je disposais sur les fichiers scn produits par Studio de Pinnacle. Vous pouvez les retrouver ici. Depuis cette date, mes connaissances sur ce type de fichier ont progressé sur trois éléments:

1) On peut dans chaque scène choisir l'image miniature qui sera affichée pour visualiser la scène. Par défaut c'est la première image, celle dont l'offset par rapport au début de la scène est 0. Dans Studio vous avez un menu contextuel qui permet de choisir une autre miniature. Cela s'intègre alors dans le fichier scn en ajoutant l'offset de cette image par rapport au début de scène. Pour signaler que cette donnée supplémentaire est présente, un indicateur est mis à $40.

2) On peut ajouter un titre aux scènes. Ce titre est affiché sur deux lignes dans Studio, mais peut éventuellement déborder sur davantage de lignes. Pour indiquer qu'un tel titre est présent, un indicateur est mis à $80. Le titre peut être en caractères UTF-8 ou UTF-16 (widechar).

3) On peut ajouter un commentaire aux scènes, qui sera ignoré dans Studio. C'est éventuellement utile pour mettre des mots-clés etc... En réalité ce commentaire, qui peut aussi être UTF-8 ou UTF-16 est toujours présent, mais en général il est rempli par une chaîne vide.

Voilà donc la nouvelle structure des fichiers avi, où j'ai au passage unifié ce que Lucien appelait le type 1 et le type 2!

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'
[nom complet du fichier]
00 00 00 00 00 00 00 00 {{nombre de scenes}} FF FF
01 00 04 00 'Clip' 50 xx yy 00 FF FF

Puis pour la première scène:

01 00 05 00 'Scene'
[commentaire_1]
(scene_1)
(longueur_1)
00 00 00 00 01 80
[fichier]
00 00 00 00
00 00 00 00
(longueur_1)
<(image_1)> si (yy and $40)<>0
<[titre_1]> si (xx and $80)<>0


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

03 80 F0 xx yy 00 05 80
[commentaire_i]
(scene_i)
(longueur_i)
00 00 00 00 07 00
(scene_i)
(longueur_i)
(scene_i)
<(image_i)> si (yy and $40)<>0
<[titre_i]> si (xx and $80)<>0


Ici ma notation est la suivante:
  • {{nombre}} est un nombre codé sur 2 octets
  • (scene_i) est le numéro de la frame dans le fichier avi où commence la scène i. Par exemple scene_1 est 0. 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 (longueur_i)=(scene_i+1)-(scene_i)
  • <> si condition : signifie que l'élément est optionnel, et il n'est présent que si la condition est remplie
  • [texte] est une chaine de caractères précédée de sa longueur et éventuellement de caractères de code selon une des syntaxes suivantes:
00 => texte vide
{len} avec len<$FF => texte UTF-8 de longueur len
FF {{len}} avec len<$FFFE => texte UTF-8 de longueur len

FF FE FF 00 => texte vide
FF FE FF {len} avec len<$FF => texte UTF-16 de longueur len
FF FE FF FF {{len}} avec len<$FFFE => texte UTF-16 de longueur len

{len} est la longueur du texte sur 1 octet
{{len}} est la longueur du texte sur 2 octets - donc toujours précédée du code $FF
Le code FF FE FF signifie donc que le texte est en widechar, chaque caractère étant codé sur 2 octets.

samedi 1 septembre 2007

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.

mardi 7 août 2007

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.

samedi 7 juillet 2007

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.

vendredi 6 avril 2007

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.