Première journée de capture

J'ai emporté mon nouveau camescope pour un dimanche en province où j'ai filmé différents épisodes de mes visites.

Je vous passe quelques surprises à propos de son fonctionnement, du genre le bouton marche/arrêt qui est remplacé par l'ouverture de l'écran ou du viseur. Il y a aussi des réglages d'usine qui ne me conviennent pas et qu'il faut changer à travers un menu tactile au fonctionnement d'abord un peu déroutant. Parmi ces réglages, il m'a fallu par exemple trouver comment désactiver la fonctionnalité qui enregistre une photo chaque fois que quelqu'un sourit!

Je découvre aussi après mes premières captures qu'elles n'ont pas été faites avec la qualité maximale 1920x1080 en 24Mbits/sec, mais seulement en 1440x1080. Je modifie donc manuellement ce réglage, car après tout si j'ai acheté un camescope HD, autant profiter de la qualité maximum!

Mais au total ce rodage se passe bien, et mon camescope revient le dimanche soir plein de souvenirs. Ils apparaissent sous forme de vignettes, une par scène, que l'on peut visualiser sur l'écran intégré. Bien entendu, c'est encore mieux de les visualiser sur ma TV écran plasma Full HD. Sauf que Sony n'a pas joint au package le cable HDMI qui le permettrait confortablement.
C'est un cable qui comprend d'un côté une prise mâle HDMI à brancher sur la TV et de l'autre une prise mâle mini HDMI, plus petite, à brancher sur le camescope. Pour être juste, d'autres possibilités de raccordement existent et sont fournies, donc la frustration n'est pas trop forte. Ce câble paraît cependant un achat complémentaire indispensable. Tout comme l'achat d'une batterie supplémentaire, car la capacité de celle qui est fournie d'origine (modèle NP-FV50) a été le facteur limitant pour ma journée de tournage.

Au bout du compte, le résultat sur ma TV a été tout à fait convaincant et démontre la supériorité du HD sur le DV: vidéos absolument non pixellisées même sur un très grand écran regardé de près, vidéo nativement au format 16x9, lecture directe possible de chaque scène sans devoir rembobiner ou avancer une cassette. La principale faiblesse reste à mes yeux dans les mouvements horizontaux de la caméra où l'entrelacement de l'image ne suffit pas à garantir une fluidité parfaite.

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.

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.

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.

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.