Attention : cet article est aujourd'hui (très) ancien ! Les instructions données ne sont peut-être plus à jour et peuvent nécessiter des ajustements pour fonctionner. Néanmoins, le matériel utilisé et le principe décrit ici restent d'actualité.
Comme beaucoup de personnes ayant connu les années 90 (voire 80), j'ai encore des traces de ce qui représentait alors le summum de la technologie grand public de l'époque : j'ai nommé le caméscope-analogique-aux-couleurs-qui-bavent. Ces traces sont présentes chez moi sous la forme de cassettes VHS. Malgré la faiblesse de ce support, ce qu'elles renferment tient pourtant de l'inestimable : des souvenirs de vacances, d'anniversaires, de Noëls en famille, ...
C'est pourquoi j'ai pris la décision on m'a fortement incité à prendre la décision de numériser toutes ces bandes avant qu'elle ne disparaissent irrémédiablement, elles ou leur lecteur associé (appelé "magnétoscope", j'en avais parlé là de manière pas du tout ironique).
Cela faisait déjà pas mal d'années que je ne m'étais plus tenu au courant de ce qui se faisait en terme de capture vidéo sur PC, j'avais seulement des souvenirs assez flous du début des années 2000 où le matériel était clairement limitant : cartes dédiées hors de prix, pilotes et logiciels associés partiellement instables, débits d'écriture liliputiens, espace de stockage ultra-limité (les disques aux prix accessibles ne dépassaient pas les 40 Go), puissance CPU imposant de lancer les tâches de transcodage la nuit...
Tout ça pour finalement se rendre compte que les paramètres définis n'étaient finalement pas bons et qu'il fallait attendre la nuit suivante pour relancer le processus ! (dans un autre cas, le PC avait simplement planté lamentablement sous la charge)
C'est donc avec une légère crainte provenant du fond des âges que j'ai commencé mes recherches concernant l'acquisition du matériel adéquat pour numériser la poignée de cassettes qui se tenaient sur mon bureau. Même si les données que je devais extraire n'avaient pas de prix, j'avais placé une limite haute de budget à 80€, en espérant plutôt trouver un compromis à 50€ car il s'agirait certainement d'une opération unique que je n'aurais ensuite plus à refaire (ça et la période de Noël qui dit aussi grosses dépenses à côté).
USB-Live 2 (Hauppauge)
Après une séance de lèche-vitrine sur les principales boutiques en ligne et la lecture de quelques comparatifs, mon choix s'est porté sur l'adapteur "USB-Live 2" d'Hauppauge, que j'ai trouvé à 40€ sur LDLC.
Comme son nom l'indique, il s'agit d'une "carte" externe, compatible USB 2.0 - point important : cela peut être clairement limitant si on traite de la vidéo HD, mais n'est pas mon cas - disposant de 3 connecteurs RCA (dits "cinch") et d'un connecteur S-Video. Je n'avais aucune assurance concernant sa compatibilité avec Linux mais son prix était clairement intéressant, donc même si mon objectif était de réaliser les captures sous Linux, j'étais prêt à y renoncer en dernier recours.
Les premiers tests
N'étant pas chez moi pour les fêtes, j'ai tout d'abord testé l'appareil sur un PC équipé de Windows XP. Après l'installation de la partie analogique (un magnétoscope Schneider 65DV20, pour information), les éternelles installations de pilotes suivies par les non moins éternels redémarrages, j'ai pu faire l'amère constatation que... je n'avais pas les bon câbles.
En effet, même si j'avais prévu l'adaptateur Péritel/RCA et les câbles Composite, aucun signal ne semblait arriver à la carte. En cherchant un peu, j'ai réalisé qu'il me fallait un adaptateur d'un type différent : celui que j'avais ne fonctionnait que dans le sens Composite -> Péritel et non l'inverse. Or ici la Péritel était branchée en sortie du magnétoscope, et le signal sortait par les prises RCA. (je n'ai pas poussé plus loin mes investigations, donc si quelqu'un tient à me corriger, qu'il n'hésite pas)
Le montage à l'arrache (donc qui ne marche pas)
En faisant quelques courses le lendemain, j'ai évidemment fait un tour du côté HIFI d'un Géant Casino afin de voir si par hasard je pouvais éviter la commande en ligne. Bien m'en a pris car j'ai trouvé un adaptateur Philips correspondant avec un câble de 1,5m pour à peine 8€. Si tout allait bien, je restais encore dans mon budget ! :)
Pour information, je n'ai pas la référence exacte mais il s'agit d'un câble équipé 3 prises RCA d'un côté (2 audio + 1 vidéo) et d'une Péritel de l'autre. Un bouton sur la Péritel permet de choisir le sens du flux : IN ou OUT. Ici c'est OUT qui m'intéresse.
Avec le câble adaptateur Philips (le bouton sur la Péritel est positionné sur "OUT")
Sous Windows...
De retour sous Windows, les tests ont été plus concluants. "Plus" oui, mais pas totalement. J'arrivais enfin à obtenir le signal sur le logiciel WinTV fourni avec la carte, mais celui-ci était brouillé, un peu comme... s'il n'était pas décodé en SECAM. Ah, le bonheur de ces formats antiques ! Grr...
J'ai dû chercher une bonne paire d'heures avant de me rendre compte que ce que je prenais pour la fenêtre de modification du format de lecture (NTSC, PAL, SECAM, etc.) n'était en fait que la fenêtre de configuration générale du dispositif de capture, et que la liste permettait seulement de consulter les formats supportés (je résume, mais c'est à peu près aussi bête). Pour changer le standard de codage à la volée au cours de la capture, il suffisait de... changer de chaîne.
La carte est en effet vue comme un tuner, et changer de chaîne permet de passer d'un standard à un autre, ce qui, lorsqu'on a trouvé le bon, donne immédiatement une image claire (enfin, pour autant qu'on puisse considérer ce type d'image analogique comme "clair", mais c'est une autre histoire).
J'ai immédiatement tenté la capture de la première cassette.
Trois heures plus tard (la durée de la cassette...), le logiciel WinTV avait généré un fichier TS de 8 Go environ contenant deux flux : un flux vidéo encodé en MPEG-2 et un flux audio encodé en MPGA (appelé "MP2"), ce qui est je crois le format des DVD. Le tout était évidemment désentrelacé, et la synchronisation vidéo/audio parfaite d'un bout à l'autre.
Un très bon point.
Puis sous Linux...
Maintenant que je m'étais assuré que le montage fonctionnait sous Windows, je pouvais faire le test sous Linux. Ayant sur moi mon vaillant PC portable de 2009 tournant sous Archlinux, j'ai branché la carte USB et commencé mes recherches sur le grand Nain Ternet. Les premiers résultats étaient moyennement encourageant : le wiki de LinuxTV indiquait qu'un noyau récent supportait "probablement" cette carte, mais un autre paragraphe était moins enthousiaste.
Pour tester cela semblait simple : brancher la carte et lancer xawtv.
# pacman -Sy xawtv
$ xawtv
Et effectivement, j'ai branché la carte sur un port USB libre, installé et lancé xawtv, et miracle : l'image apparut correctement dans le petit cadre !
Bon, impossible de l'agrandir sous peine de perdre la moitié de l'affichage - remplacé par une bande verte - mais qu'à cela ne tienne ce n'était pas pour du visionnage en plein écran que je souhaitais utiliser la carte mais pour de la capture vers un fichier. J'étais sur la bonne piste.
xawtv sous Gnome 3
Première étape : la capture
De retour dans mon atelier chez moi, sur mon fidèle Freeseed bi-core équipé lui aussi d'Archlinux, j'ai cherché comment enregistrer le flux de la manière la plus brute possible, même si cela devait signifier de créer des fichiers de 10 à 20 Go par heure. Mon objectif était dans un premier temps de créer des enregistrements simples que je pourrais retravailler et transcoder après coup.
J'ai tout d'abord regardé du côté de VLC, véritable boîte à outil vidéo multi-plateforme.
Seulement, à mon grand désespoir, si j'arrivais bien à obtenir l'image en utilisant la configuration prédéfinie "TV (analogique)", le son lui manquait, et l'erreur suivante apparaissait :
La lecture du fichier a échoué. VLC n'a pas pu ouvrir le fichier "/home/nanawel/hw:2,0". (aucun fichier ou dossier de ce type)
L'erreur obtenue sous VLC
Évidemment qu'il n'y a aucun fichier à cet emplacement, mais ce n'est pas ce que je te demande, banane !
Après une rapide recherche infructueuse pour déterminer d'où pouvait bien provenir le fait que VLC essaye d'ouvrir le périphérique audio comme un fichier dans le dossier courant, je me suis finalement tourné vers mplayer et son acolyte mencoder. J'ai trouvé des exemples de commandes permettant a priori de faire ce que je voulais, alors je les ai essayées.
L'enregistrement serait fait dans un conteneur AVI, en utilisant le codec vidéo MJPEG et le codec audio PCM (ce qui est connu comme le format "wave" sous Windows). Il s'agit d'un des fomats les plus simples et les plus "bruts" : la vidéo est mise sous forme d'images JPG indépendantes (il y a donc une compression mais sur chacune des images, pas sur le flux), et le son est conservé sous forme d'onde échantillonnée, donc sans aucune compression.
Puis j'ai testé.
Longuement.
Laborieusement.
Le premier test m'a donné une vidéo en accéléré alors que le son était au rythme normal. J'ai alors ajouté les paramètres "-noskip" et "-mc 0" pour conserver les frames. Le résultat semblait bon, alors j'ai lancé la capture d'une seconde cassette de trois heures.
Lors d'un visionnage attentif de la vidéo générée, j'ai réalisé qu'après une heure environ le son était en retard par rapport à l'image, et que ce retard se creusait progressivement pour atteindre les 4 à 5 secondes en fin de fichier. Inacceptable.
(2 jours plus tard...)
Après moult essais à base de combinaisons de paramètres obscurs, filtres vidéo ("harddup", "softskip" et autres), incantations magiques et tentatives d'envoûtement (en dernier recours) qui n'ont jamais corrigé ce rogntudju de décalage entre le son et l'image, j'ai décidé de me reconcentrer sur VLC. Mes recherches montraient clairement que lorsqu'un problème n'était pas résoluble par mencoder, il fallait tenter VLC (et réciproquement).
Le problème du périphérique de son évoqué plus haut a été "simplement" résolu en préfixant la valeur proposée dans la liste "hw:2,0" par "alsa://". Les joies du son sous Linux où OSS, Alsa, Pulse et les autres s'ébattent joyeusement dans une mare de caca.
Voici finalement la boîte de dialogue avec la configuration fonctionnelle, celle affichant, dès l'appui sur le bouton "Lire" l'image provenant de la carte d'acquisition et le son associé :
La configuration fonctionnelle sous VLC
Ce qui est intéressant c'est que si je souhaitais, disons par exemple, créer un petit script pour enregistrer le flux via VLC, je n'ai qu'à prendre les options de lecture qui apparaissent en cochant "Afficher plus d'options".
La commande pour simplement lancer la lecture dans VLC va donc se traduire par :
$ vlc v4l2:///dev/video0 :v4l2-standard=SECAM_LC :input-slave=alsa://hw:2,0 :live-caching=300
Ça, c'est pour lire. Moi je veux enregistrer. La commande complète serait donc celle-ci :
$ cvlc v4l2:///dev/video0 :v4l2-standard=SECAM_LC :input-slave=alsa://hw:2,0 :live-caching=300
:sout=#transcode{vcodec=mjpg,acodec=mpga,vb=1024,ab=160}:standard{access=file,dst=out.mpg}
Ce qui signifie :
- Utiliser la version "console" de VLC (pas d'interface graphique, donc pas de suivi de la vidéo. Utiliser "vlc" à la place de "clvc" pour retouver l'interface)
- Lire la vidéo sur le périphérique V4L /dev/video0
- Lire le son sur le périphérique ALSA hw:2,0 (à adapter selon la configuration matérielle, etc.)
- Utiliser le standard de codage SECAM L/C (ce que xawtv me sélectionnait automatiquement plutôt que "SECAM L", je n'ai pas trouvé ce qui différenciait les deux)
- Transcoder la vidéo en utilisant le codec MJPEG (pareil qu'avec mencoder) avec un bitrate de 1024k
- Transcoder le son en utlisant le codec MPGA (MP2) avec un bitrate de 160k
- Écrire le tout dans un fichier "out.mpg", qui, d'après l'extension, sera un conteneur MPEG-PS (sinon on peut forcer le muxer en utilisant le paramètre "mux=...").
Pour connaître les codecs et muxers utilisables, voir cette page :
https://wiki.videolan.org/Codec
MAIS.
J'obtenais encore une fois un décalage entre le son et l'image : cette fois-ci le son était en avance. Grr de grr.
Il a fallu que je change le codec vidéo et passer par du MPEG-1 (toujours avec du MP2 en audio) pour enfin obtenir une vidéo synchronisée de bout en bout !
Ma commande "finale" est donc :
$ vlc v4l2:///dev/video0 :v4l2-standard=SECAM_LC :input-slave=alsa://hw:2,0 :live-caching=300
:sout=#transcode{vcodec=mp1v,acodec=mpga,vb=1024,ab=160}:standard{access=file,dst=out.mpg}
J'ai pu ainsi numériser tranquillement toutes les cassettes restantes, et créer des fichiers MPG propres que je pouvais ensuite transcoder et compresser à loisir dans un second temps. Pour information, à la fin de cette première phase on obtient des fichiers pesant 6 à 7 Go par heure, ce qui est très acceptable AMHA.
Mise à jour 2016-05-16 : Si la combinaison MPEG-1/MP2/MPEG ne donne pas une qualité suffisante, essayez en passant par du MPEG-2/MP2/TS, plus adapté notamment aux flux entrelacés.
Soit en commande VLC : vcodec=mp2v,acodec=mpga et un nom de fichier en *.ts
Et n'hésitez pas à gonfler le bitrate sur cette phase, on transcodera ensuite.
Afin de conserver la trace de ces commandes et pouvoir les adapter et les réutiliser au besoin, j'ai créé un script Bash auto-explicatif très simple disponible ici :
Pour l'utiliser :
$ record_vlc.sh [<duree>]
Où
Ne pas oublier de configurer correctement les variables VIDEO_DEV et SOUND_DEV en début de script.
Deuxième étape : redécoupage et transcodage
Là je vais résumer par flemme, mais ce fut encore perte de temps et compagnie, car en plus de vouloir transcoder les films bruts dans un format un peu plus économe en terme d'occupation sur le disque, je souhaitais recouper le film : supprimer les quelques secondes initiales, et souvent les nombreuses minutes à la fin (ayant lancé la commande pour numériser la totalité de la cassette, même si parfois seule une partie était réellement utilisée).
J'ai réessayé mencoder, qui normalement est fait pour cela. Mais j'obtenais de nouvelles désynchronisations dans les vidéos résultantes, ou (selon le codec testé) des corruptions dans le son. OK je passe au suivant.
VLC m'a donné peu ou prou la même chose, avec au final un résultat décevant. Impossible notamment de bien recouper le film à partir d'un point jusqu'à un autre.
Puis je suis passé à ffmpeg. Et enfin, ce fut le bon ! Je pouvais redécouper correctement les morceaux qui m'intéressaient et encoder la vidéo dans un format un peu plus efficace : MPEG-4 (avec le son en MP3), le tout enrobé dans du bon MKV.
Voici donc la commande utilisée pour ce faire :
$ ffmpeg -i in.mpg
-c:v mpeg4 -b:v 6000k -c:a mp3 -b:a 160k
out.mkv
J'ai également créé un script Bash auto-explicatif permettant de configurer le transcodage. Il est disponible ici :
Pour l'utiliser :
$ transcode_ffmpeg.sh <fichier> [<debut> <fin>]
Où
J'obtiens ainsi des fichiers dont la taille a été divisée par un peu plus de 2 (exemple : 9,7Go après conversion par ffmpeg pour 21,8Go après l'enregistrement "brut" par VLC). La différence de qualité est, elle, imperceptible (pour moi).
Voilà c'est tout. J'espère encore une fois ne pas avoir dit trop de c... bêtises, et que le récit de mes péripéties pourra être utile à quelqu'un souhaitant aussi mettre en lieu sûr ses précieux souvenirs analogiques des années 80 et 90. Si j'en juge par le peu d'informations utilisables (et à jour) que j'ai pu dénicher sur la Toile, je pense que oui.