Carnet Wiki

VideoSPIP

Version 8 — November 2008 tetue

Retour aux comptes-rendus

Retranscription de 05_videospip-booz-kent1-cedric-001.mp3 (54:26’, 50.0M) et 06_videospip-discussion-002.mp3 (05:41’, 5.2M).

Le site Vidéos [@ spip [Vidéos .SPIP.org->http://videos.spip.org] org /] , par Kent1 et BoOz

Voir [Voir l’exemple en ligne : [-> http://videos ligne->http://videos .spip.org /] org/spip . php?article2].

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.

Le plugin « [Le lecteur multimédia », par BoOz et Kent1

multimédia->http://www . spip-contrib.net/Lecteur-Multimedia,308], par BoOz et Kent1

Présentation du plugin : http://www.spip-contrib.net/Lecteur...
Voir l’exemple en ligne.

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.

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 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.

Une application du lecteur multimédia en audio: le radiophone

L’application que nous avons vue précédemment (Videos.spip.org) propose de mettre en ligne des vidéos, qui seront converties en différents formats et hébergées par le serveur de Kent1 ou éventuellement un serveur distant. Il s’agit donc d’une logique centralisée, comme celle de YouTube, Daily Motion, etc. Avec le radiophone.net, BoOz propose une logique différente, une logique de décentralisation. Ce site repose en l’occurence sur de l’audio, des .mp3.

Tous les contenus qui apparaissent ici sont déjà publiés ailleurs, sur des blogs mp3, des sites de musiciens, des podcasts d’émissions de radio, etc. Ils sont agrégés dans le radiophone sur le principe des SPIPs de syndication: les adresses des podcasts (flux RSS ou autres) sont publiés dans SPIP en tant que sites syndiqués.

Le plugin podcast_client [8] de Fil récupère les fichiers .mp3 de chaque fil RSS et les transforme en documents distants. Ces documents restent attachés aux articles syndiqués. Ensuite, on peut donc appeler ces fichiers grâce à des boucles (DOCUMENTS). Par exemple, la page d’accueil du radiophone contient une boucle (DOCUMENTS) {extension==mp3} {par date} {inverse}.

Il s’agit de documents distants dont on ne réalise pas de copie locale: les .mp3 restent stockés sur les sites qui les ont publiés. Lorsque le visiteur appuie sur play, le javascript se réfère à l’URL du .mp3 distant. Sur le même principe que pour les vidéos, le pixel invisible en Flash est chargé de jouer le son; du javascript commande la barre de progression, l’affichage de la durée de lecture, etc. Ici aussi, le player a été complètement personnalisé, puisqu’il ne repose que sur de l’HTML, du CSS et des images (ici, les boutons de contrôle proviennent de la Blogothèque).

La page d’accueil du radiophone est une playliste: lorsqu’un morceau se termine, le player passe directement au suivant. Flash est capable de « dire » qu’un morceau est fini. Javascript récupère cette information et lance alors le morceau suivant, dont l’apparence dans la liste change pour indiquer qu’il est en cours de lecture. Donc, Javascript doit lister tous les .mp3 de la page, jouer le premier, le deuxième et ainsi de suite, et piloter le CSS en conséquence. Le script doit donc « savoir » que tel morceau est en cours de lecture, de tel le précède et tel autre le suit. Il y a donc une certaine sémantique entre ces différents [trucs: objets, langages?] qui leur permet de se communiquer cette information. Soit on invente cette sémantique, soit on se fie à une réflexion menée par d’autres pour adopter un standard commun.

C’est là qu’interviennent les microformats [9]. Le microformat qui correspond aux enregistrements audio est hAudio [10]. Utiliser le microformat hAudio signifie donner une valeur à certains attributs HTML (class et rel) qui respecte une sémantique donnée. Par exemple, <div class="haudio"> encadre la référence à un contenu audio et peut contenir un <span class="title"> qui indique le titre du morceau, un <span class="source"> qui indique le site d’origine, etc. (album, contributor, published, enclosure, category, duration, description,...). Là où aujourd’hui, nous avons besoin de RSS pour syndiquer ces informations entre des sites, demain, une page d’accueil qui respecte le format hAudio pourrait suffire: les informations actuellement fournies par le fichier RSS seraient obtenues en parsant la page d’accueil. Tout l’avenir de cette solution repose sur l’existence de pages HTML suffisamment formatées, qui utilisent des classes standardisées et rendent le RSS inutile. Un autre exemple sur le radiophone: la page du tag Jazz ne contient que des fichiers jazz et il suffirait de parser cette page pour remplir un autre site qui ne s’intéresserait qu’au jazz.

De proche en proche, il y a une réplication des contenus, mais qui reste symbolique, puisque les fichiers sont toujours stockés sur le site original. Le jour où ce site supprime le fichier, il n’existe plus non plus sur les sites qui le référencent. Le radiophone n’est finalement qu’un portail. Si on veut en savoir plus sur une chanson découverte grâce à lui, ou poster des commentaires sur une chanson, on est redirigé sur le site qui l’a initialement publiée. C’est intéressant.

Pour conclure, il faut retenir qu’avec SPIP et le plugin Lecteur multimédia, on peut complètement maîtriser l’affichage du lecteur avec les techniques habituelles (HTML, CSS, javascript) sans s’emmerder avec Flash.

Le plugin XSPF utilise une autre technique (un format XML [11]) et est actuellement le seul à proposer une playliste qui mélange le son et la vidéo, mais il reste tributaire d’une présentation en Flash. Il serait par contre intéressant de syndiquer la playliste XSPF, comme tout RSS extérieur, et de l’afficher avec le plugin Lecteur multimédia. Il suffirait d’écrire le parseur ;-).

L’API du « one pixel player » se trouve sur le site de la librairie javascript SoundManager 2 [12] et est très bien documentée. On y trouve aussi le player, un fichier d’1x1 pixel, qui pèse 16k.

Le plugin Kaltura, par Cédric