Version 5 — Novembre 2008 — Déesse A.
Retranscription de 05_videospip-booz-kent1-cedric-001.mp3 (54:26’, 50.0M) et 06_videospip-discussion-002.mp3 (05:41’, 5.2M).
Principe
Sur Videos.spip.org, les vidéos sont publiées sur le principe du contenu généré par les utilisateurs, à la façon de Daily Motion ou de YouTube, sauf qu’on le fait nous-mêmes. Videos.spip.org est justement un petit Daily Motion en SPIP.
Ce qui intéressait Kent1 quand il a décidé de lancer Videos.spip.org, c’est de gérer toute la post-production vidéo à travers SPIP, c’est-à-dire, après l’étape de montage, gérer l’encodage des vidéos au format souhaité, tagger les images et les gérer dans le site Web. Comme il n’avait pas besoin de le faire pour lui, il a décidé de le faire pour SPIP en créant un site de tutoriels. Maintenant, trois ou quatre personnes travaillent sur ce projet, font des squelettes, des plugins...
L’idée est de proposer un dispositif de squelettes et de plugins aux gens et à d’autres hébergeurs éventuels, qui leur permette d’héberger eux-mêmes leurs vidéos, de les compresser dans différents formats, et aussi de gérer des sons.
Fonctionnement
Videos.spip.org est installé sur un serveur dédié sur lequel la limite d’upload est fixée à 300M. Pour l’instant, seuls certains formats sont acceptés : .mp4, .mov, .mpg... mais il ne devrait pas y avoir de problème pour en intégrer d’autres.
La chaîne se déroule comme suit.
- Il y aura une page intermédiaire d’explication et de login qui amènera ici : ?page=ajouter_video. Cette page permet d’uploader la vidéo par HTTP.
- La page ajouter_video comporte un texte d’introduction. Le bouton bleu en Flash permet de sélectionner le fichier.
- Lorsqu’on a sélectionné le fichier, le script le vérifie, le texte d’introduction disparaît et la barre de progression (qu’Izo va faire ;-) apparaîtra, affichera le pourcentage et une image au bout du processus.
- On indique le titre et la catégorie, un texte facultatif et quand on validera, l’upload de la vidéo se poursuit.
- L’upload peut durer une heure, trois heures, cinq heures... ça dépend de la taille de la vidéo.
- Lorsque c’est terminé, un article SPIP est automatiquement créé, qui comporte la vidéo originale (au poids original) et la vidéo encodée dans le format définit dans la configuration.
Ici, nous avons choisi l’encodage des vidéos en MP4, pour qu’elles soient téléchargeables sur les iPhones ; en FLV, pour qu’elles soient lisibles directement sur le Web et en OGG Theora. Le OGG ne s’affiche pas pour l’instant et ne s’affichera que lorsque le navigateur du client sera Firefox 3.1, grâce à la balise <video> [1].
Ces trois encodages sont gérés par le plugin SPIPmotion [2]. Cela nécessite un serveur dédié parce qu’on a besoin de puissance derrière. Le serveur doit disposer d’FFmpeg [3], un logiciel d’encodage de vidéo. Si l’extension ffmpeg-php [4] est installée, lorsqu’une vidéo est ajoutée, le script récupère la 214e frame (il s’agit d’un réglage) qui deviendra le logo du document, la durée de la vidéo, sa taille (largeur et hauteur) et, si la vidéo est bien taggée (c’est rare), le titre, le texte et le copyright. Le script récupère donc les méta-données de la vidéo.
Concernant les formats, FFmpeg gère la plupart des formats vidéo [5]. Le seul problème qui peut se poser concerne certains codecs. FFmpeg est un logiciel libre, mais certains codecs sont soumis à des licences propriétaires. Parmi ceux-ci, certains permettent néanmoins un usage gratuit (ex. h264, FLV 1....), mais d’autres obligent à payer une redevance (ex. codecs Sorenson pour le FLV 1.1). Ces derniers ne sont donc pas utilisés ici. Mais avec le FLV 1., on obtient néanmoins une qualité correcte, selon les réglages utilisés. Son désavantage est de ne pas contenir de méta-données ; elles doivent alors être ajoutées avec FLVTool [6]. FLVTool lit le fichier et reconstruit des méta-données telles que la durée de la vidéo. Ceci est nécessaire, en gros, pour permettre l’avance et le recul rapides dans la vidéo.
Le formulaire d’upload pourrait facilement être adapté au son et utiliser le plugin getID3 [7]. Celui-ci récupère tous les tags ID3 d’un fichier son. Kent1 l’a déjà utilisé pour un site dans lequel il se basait sur ces tags pour créer des auteurs, une rubrique selon le titre de l’album, etc. Mais cela pourrait être configurable à souhait, par exemple via des filtres. De cette manière, il a pu importer 5.000 sons en l’espace de 20 minutes. Ceux-ci étaient déjà uploadés par FTP, il n’y avait plus qu’à les importer et toutes les données sont récupérées automatiquement.
Lorsque l’upload est terminé, la page affiche :
- le logo du document (la 214e frame de la vidéo extraite automatiquement) ;
- le type MIME du fichier (ex. application/mp4) ;
- le format (largeur et hauteur en pixels) ;
- le poids du fichier ;
- la durée en secondes ;
- le nombre de frames ; etc.
Toutes ces infos sont récupérées automatiquement.
Le script ajoute alors cette vidéo dans une file d’attente chargée par spip_cron. D’ailleurs ceci devrait changer parce que spip_cron ne cron pas quand il n’y a pas de visite, ce qui est souvent le cas quand on teste un site.
Le script définit la taille (largeur x hauteur) de la vidéo finale, mais celle-ci n’est redimensionnée que si la largeur originale est supérieure. Une vidéo de largeur inférieure aux paramètres par défaut sera laissée à ses dimensions originales. Par défaut, la vidéo est recadrée à 480x360px.
Les trois encodages sont systématiquement réalisés, les uns à la suite des autres. C’est pourquoi les fichiers sont mis dans une file d’attente, pour ne pas surcharger le serveur. Mais le choix d’encoder dans trois formats correspond à un souci de pérennité et de simplification de la diffusion.
Tant que l’encodage n’est pas terminé, l’article n’est pas publiable mais son contenu peut être modifié et sauvegardé par l’auteur. Le titre, le texte, etc. peuvent être mis à jour même si la vidéo est encore dans la file d’attente, car on ne sait pas à l’avance quand l’upload sera terminé.
Quand l’encodage est terminé, l’auteur reçoit un mail contenant l’URL de la page d’upload (wouaw !). Sur cette page, la capture est remplacée par un player qui permet de visualiser le rendu.
La page permettra de réencoder la vidéo avec des paramètres différents. En effet, il est très difficile de définir ces paramètres en amont. On peut définir des paramètres par défaut, plus ou moins propices à tous les encodages, mais ils ne fonctionneront pas pour certaines vidéos. Par exemple, il arrive que le désentrelacement fonctionne mal avec certaines vidéos. Il est donc parfois nécessaire de relancer le processus d’encodage avec des options qu’on définit manuellement.
La page lui propose alors de publier l’article, de supprimer complètement la vidéo (si le rendu est trop pourri), d’uploader une autre vidéo, etc. En effet, la publication requiert une action de l’utilisateur, elle n’est pas automatique. Il ne peut pas non plus décider à l’avance que la vidéo soit publiée automatiquement à la fin de l’encodage, car il reviendrait alors aux administrateurs du site de vérifier la qualité de l’encodage. Ici, dans ce projet communautaire, on préfère que l’auteur soit responsable de vérifier la qualité de sa vidéo et de relancer éventuellement l’encodage. Un peu comme sur Spip-contrib, on ne corrige pas les fautes d’orthographe des auteurs, chacun est responsable de ce qu’il publie.
Conclusion
Pour conclure, et rejoindre l’exposé de Romy, les documents joints sont un enjeu qui devient assez important pour tous les CMS. Demain, la rencontre au cinéma Nova est également axée, non pas sur le contenu du site Web, mais directement sur la mise à disposition de formats vidéos. La question de la mise en ligne d’œuvres ou contenus artistiques, notamment vidéo, se pose pour beaucoup de monde.
Cela fait trois ou quatre ans que BoOz est au taquet sur les façons de jouer de la vidéo et du son sur Internet. Cela a toujours été compliqué, pour différentes raisons. Des raisons de progrès technique : il faut que les industriels et les ingénieurs informaticiens produisent de quoi afficher du son et de la vidéo sur des pages Web. Et puis des problèmes juridiques : il y a des batailles entre différents formats, des industries qui imposent leur format et empêchent de trouver des formats convergents. Donc, jusque récemment, c’était l’enfer la merde .
Avec l’essor de YouTube notamment, de plus en plus de players Flash sont apparus et de gros progrès ont été faits sur l’affichage des vidéos, mais c’est un phénomène récent, datant d’un an et demi ou deux ans maximum. Et depuis un an au plus, il est devenu possible de jouer du son ou d’afficher de la vidéo en passant par Flash mais en le limitant au minimum.
D’une part, on a un objet Flash d’1x1 pixel, invisible donc, dont on se sert uniquement pour jouer le son. D’autre part, une simple <div> contenant l’objet Flash qui va afficher la vidéo. Mais la grande différence, c’est que tout le reste est habillé à l’aide d’HTML, d’images et de CSS, sans Flash : les boutons de contrôle sont des images (celles-ci ont été réalisées par baroug) ; la barre de progression qui permet de voir l’avancement du chargement (en gris) et de la lecture (en rouge) sont de simples div coloriées en CSS. Et puis l’interaction entre l’HTML et le Flash est assurée par javascript : il envoie à ce pixel Flash l’URL du son à jouer, les commandes demandées par l’utilisateur lorsqu’il appuie sur les contrôles en images ; le Flash lui renvoie l’information sur l’avancement de la lecture qui lui permet de contrôler la barre de progression, etc.
Si le javascript était désactivé ou le lecteur Flash absent, un lien vers le fichier .flv est prévu, qui permet de le télécharger pour le regarder dans son lecteur (VLC par ex.).
Il devient donc facile de créer l’aspect de son lecteur (skinner le player :-), avec des technologies (HTML, CSS, images) accessibles à chacun, sans plus besoin d’acquérir la licence du logiciel qui permet d’éditer du Flash. Par ailleurs, en maîtrisant javascript, il est possible de créer de nouvelles actions, qu’on peut éventuellement déclencher en fonction de la lecture du film (puisque le Flash renvoie le temps de lecture en millisecondes). Par exemple, on pourrait décider d’afficher une icône sur la page toutes les dix secondes, en définissant ce comportement dans l’action javascript appelée par le Flash lors du chargement.
Il devient intéressant de personnaliser son lecteur au niveau des actions lorsque le son ou la vidéo ne sont pas au centre de (la concentration dans ?) la page. Si, par exemple, le son ou la vidéo ne sont pas directement l’objet de la page, on peut jouer avec le rendu, les activer ou pas, baisser ou augmenter le volume, en fonction d’autres événements.
Sous le lecteur, on affiche une playliste des vidéos jointes à l’article. Lorsqu’une vidéo se termine, le lecteur passe automatiquement à la suivante. Un autre exemple de personnalisation des actions en javascript est donné par Marcimat. Il a créé un site pour les enfants – le site des Petits débrouillards – dont une page contient une grande image du désert avec des animaux. Quand on passe sur un renard avec la souris, une boîte explicative s’affiche et le player pousse le cri du renard. En fait, le survol par la souris est repéré facilement en javascript, qui commande alors au lecteur d’envoyer tel son, correspondant à l’animal dont l’image est survolée.
Dans ce lecteur-ci, le javascript utilisé fait partie de la librairie jQuery.
On utilise Flash parce qu’à l’heure actuelle, c’est la seule technique qui permette de rendre facilement de l’audio ou de la vidéo sur une page Web, quel que soit le navigateur. Mais la grosse intelligence est de limiter tous les traitements à ce pixel et de dissocier l’affichage du résultat. C’est très récent et très malin. Du coup, on n’a pas besoin de se casser la tête à trifouiller ce fichier Flash. Quelqu’un Un mec s’est cassé la tête au début pour implémenter les fonctions de base (play, next...) et nous devons juste nous concentrer sur ce qu’on sait faire : le CSS, l’HTML, etc.