Carnet Wiki

VideoSPIP

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). Les mp3 ne sont plus accessibles.

Le plugin SpipMotion, par Kent1 et BoOz

-  Le plugin SPIPmotion
-  Videos.spip.org

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.0...), 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.0, 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 Lecteur multimédia, par BoOz et Kent1

-  Le plugin Lecteur multimédia
-  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 faut donc qu’une sémantique portée par les différents objets de la page HTML permette de 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 sur ce thème, et il suffirait de parser cette page pour nourrir 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 les contraintes du 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

-  Le plugin Kaltura
-  Exemple en ligne [prochainement sur obiwine.com.]

Avec Videos.spip.org, nous avons abordé des méthodes d’encodage et de diffusion de son et de vidéo sur des sites Internet, basées sur un ensemble de solutions libres, qui nécessitent de déployer un serveur. Cette solution constitue une alternative par rapport à Vimeo, YouTube et autres, qui, eux, proposent gentillement de s’approprier notre contenu. Ces prestataires hébergent et diffusent notre contenu apparemment gratuitement, mais en réalité, ils en disposent, peuvent nous empêcher de le récupérer. Nous renonçons à la propriété sur la vidéo, nous leur donnons les droits intellectuels qui y sont attachés. La solution mise en place par Kent1 a pour avantage de rester maître de son contenu, ne pas devoir intenter un procès à YouTube pour le récupérer dans dix ans. Elle est sans doute ce qu’on peut faire de mieux (si, si !) lorsque l’on veut rester propriétaire de ses vidéos stratégiques, lorsque l’on veut rester libre. Mais cette solution a un coût, parce qu’elle nécessite un serveur, et s’adresse donc plutôt à des associations qui ont les moyens de la déployer, de choisir cette stratégie. Elle répond donc à une problématique mais ce n’est pas une solution universelle.

De toute façon, il n’y a pas de solution miracle pour la vidéo, il n’y a que des ennuis. Avant les solutions où l’encodage dans différents formats se réalise sur le serveur d’hébergement, les clients devaient encoder eux-mêmes la vidéo dans le bon format (par exemple .flv) et devaient donc disposer de Flash par exemple. Résultat, on ne le faisait tout simplement pas. Les outils techniques qui permettent d’afficher de la vidéo sur un site commencent à se simplifier. Sans doute la balise <video> de l’HTML 5 sera une partie de la solution. La balise contient simplement l’URL d’un fichier vidéo, au format ouvert Ogg Theora [13] et la lecture se lance directement dans le navigateur, sans plus besoin d’installer les différents lecteurs propres à chaque format vidéo. Cette innovation permet donc de s’affranchir de plusieurs problèmes, notamment celui des codecs propriétaires. Mais il faudra quelques années avant que l’HTML 5 ne soit disponible dans tous les navigateurs.

L’alternative proposée ici a l’avantage qu’elle est plus simple à déployer que la mise en place d’un serveur dédié, mais elle repose sur un prestataire externe commercial. Elle demande donc de renoncer à la maîtrise de ses contenus. Il faut en être conscient, mais cela peut répondre à certaines problématiques.

Kaltura

Le prestataire est Kaltura, une entreprise commerciale. Kaltura annonce une solution open source. Si toutes les sources de la partie publique, l’API, etc. sont effectivement disponibles, par contre, côté serveur, les sources ne sont pas publiées. Donc, pour le moment, il n’est pas envisageable de monter son serveur et de proposer la même application. Comme souvent, le projet tel qu’il est présenté au début est assez ouvert, mais il faut surveiller son évolution qui va petit à petit tomber dans le business.

Leur concept s’apparente à du forum vidéo, de la vidéo contributive : un internaute propose une vidéo et d’autres peuvent lui ajouter un commentaire sous forme de vidéo. On obtient donc un thread dans lequel quiconque peut poster et le résultat final est la concaténation de toutes les contributions. Cédric, lui, l’utilise sur son site uniquement comme enregistreur et lecteur vidéo, il n’a pas implémenté le système des commentaires.

Leur offre de base, gratuite, inclut jusqu’à 3G de streaming (lecture) par mois. Au-delà, ils proposent des offres d’hébergement payantes.

Pour utiliser le plugin, il faut ouvrir un compte chez Kaltura et obtenir la clé API [API key]. On a alors accès à un backoffice qui permet d’administrer les vidéos, c’est-à-dire, toutes les contributions du thread.

Le plugin

Hormis le choix stratégique de ne pas utiliser le YouTube de Google, Cédric a choisi ce prestataire parce que son API permet de proposer aux visiteurs de son propre site d’y uploader de la vidéo sans s’identifier préalablement chez Kaltura. Lorsque l’on veut utiliser les API de Vimeo et consorts pour permettre à l’internaute d’uploader de la vidéo dans son propre site, celui-ci doit créer un compte et s’identifier sur l’autre plateforme, puis revenir sur le premier site pour uploader. Ceci est parfois gênant. En particulier, l’application développée par Cédric se trouve sur un site de type réseau social, donc, l’internaute a déjà dû s’identifier une première fois pour arriver au formulaire d’upload. Ce ne serait pas agréable de lui demander de s’identifier une seconde fois chez le prestataire externe. L’API de Kaltura prévoit cela et propose que l’upload puisse se réaliser via un site distant, avec une seule clé, et différents noms (les vidéos restent attribuées à leurs auteurs respectifs).

Le plugin SPIP Kaltura propose une balise #FORMULAIRE_EDITER_KALTURA qui insère l’application de Kaltura. C’est donc l’interface de Kaltura qui apparaît comme formulaire d’ajout de vidéo. Du point de vue de l’utilisateur, elle est bien conçue. Elle permet d’uploader des photos, de la vidéo ou de l’audio. Dans le cas de la vidéo, elle permet d’uploader un fichier, de rapatrier une vidéo publiée chez YouTube, MySpace ou autre, ou d’enregistrer directement la webcam. C’est aussi Kaltura qui se charge du post-process, de l’encodage dans le bon format.

Une fois que la vidéo est enregistrée, le plugin l’ajoute automatiquement comme document distant associé à un article et elle est incluse, player compris, dans le corps du texte avec le tag <embed>.

Le player est donc également fourni par Kaltura. Le logo de Kaltura apparaît sur la vidéo. Leur concept est de proposer à l’auteur d’inclure de la publicité, puisqu’ils proposent un service de régie publicitaire. Le lecteur n’est donc pas personnalisable. Normalement, ils livrent les sources du lecteur mais Cédric n’a pas encore regardé.

L’intérêt de ce plugin est donc la facilité de déploiement. Il peut répondre à la problématique de personnes qui veulent mettre rapidement de la vidéo en ligne et proposer à leurs visiteurs d’en publier, sans ouvrir un compte chez le prestataire externe. Mais évidemment, il faut accepter que les vidéos soient hébergées chez Kaltura et courir le risque de les perdre à long terme. Tout dépend des besoins réels.

Sur le plan légal, l’application de Kaltura demande aux contributeurs de confirmer qu’ils disposent bien des droits d’auteur sur la vidéo. Et Kaltura reste responsable de poursuites éventuelles puisqu’il est l’hébergeur. Celui qui installe le plugin sur son site n’héberge pas les vidéos et ne doit donc, a priori, pas en assumer la responsabilité légale.

La vidéo est à la mode, tout le monde en veut sur son site Web, mais il faut rester conscient que ce n’est pas toujours la meilleure manière de communiquer. C’est un moyen de communication qui ne correspond pas à l’essence du Web : les vidéos ne sont pas accessibles, les personnes qui ne les voient pas n’ont pas accès à l’information, elles sont rarement audio-doublée ou sous-titrées, le contenu n’est pas référencé, etc. Il est légitime de l’utiliser dans certains cas, mais l’essence du Web, c’est une information structurée et accessible, c’est-à-dire, du texte.

[Discussion]

Aurélie - Mise à jour :2 décembre 2009 à 08h52min