Framatube, comme les lecteurs assidus de ce blog le savent déjà, est une initiative lancée il y a environ deux ans, dans le but de regrouper des vidéos en rapport avec le logiciel libre et sa culture, pour en favoriser la diffusion.

Framatube s’appuie pour cela aujourd’hui sur la plateforme Blip.tv et, pas de mystère, sur le travail de bénévoles chargés de produire des sous-titres lorsque la vidéo est dans une langue étrangère, l’équipe Framalang entrant alors dans la danse ^[1].

Dans ce dernier cas, le travail nécessaire pour proposer la vidéo sous-titrée va au delà de la simple traduction : il faut préalablement transcrire la bande-son pour la traduire, puis synchroniser les sous-titres obtenus avec la bande-son, incruster les sous-titres et finalement encoder le tout dans un format libre. Cela demande un travail important, qui nécessite une motivation de longue haleine et plus de travail que les habituelles 6 ou 7 heures par traduction d’article publiée sur le Framablog.

D’autant que, les sous-titres étant au final incrustés dans la vidéo, tout ce travail ne peut être réutilisé pour proposer de nouvelles traductions dans d’autres langues.

Pour prendre l’analogie du logiciel, le code source qui pourrait permettre d’améliorer ou de modifier facilement le résultat n’est pas fourni : paradoxal pour un projet Framasoft !

Heureusement, la Participation Culture Foundation (fondation à but non lucratif à laquelle on doit notamment le logiciel de télévision par Internet Miro) développe « Universal Subtitles » un outil en-ligne qui simplifie grandement la tâche.

Ce projet se place sous le parrainage de la Mozilla Foundation, autre fondation à but non lucratif à qui l’on doit le fameux navigateur web Firefox et qui a initié le projet Mozilla Drumbeat pour promouvoir des initiatives comme celle-ci, visant à garder le Web Ouvert.

L’objectif d’Universal Subtitles est pour le moins ambitieux, offrir à chaque vidéo disponible sur le web un support de sous-titrage collaboratif, où chacun puisse participer au sous-titrage dans sa langue d’une vidéo rencontrée sur le web.

La solution retenue est habile puisqu’elle consiste, à partir d’une vidéo préexistante sur le Web :

1. à proposer des outils permettant de réaliser un sous-titrage de manière communautaire dont les données sont hébergées sur les serveurs du projet,
2. à générer un simple bout de code mélangeant JavaScript et HTML5 à ajouter sur son site pour afficher un lecteur vidéo personnalisé pour afficher les sous-titres à la volée en surimpression de la vidéo.

Les avantages sont nombreux :

• en associant la transcription et ses traductions aux vidéos, il devient possible d’indexer, analyser et traduire l’information contenue dans ces vidéos de façon automatique (les vidéos pourront être indexées par les moteurs de recherche aussi finement que les textes);
• le travail manuel de sous-titrage se trouve facilité et le résultat peut à tout moment être modifié, complété et amélioré par la communauté;
• tout cela contribuant à généraliser le sous-titrage et la traduction des vidéos, bénéficiant au plus grand nombre d’une part et augmentant d’autant l’accessibilité de ce support de communication. Les personnes atteintes de handicaps visuels ou auditifs pouvant à nouveau (comme aux débuts du web) bénéficier de versions textes lisibles à son rythme ou par un vocalisateur.

Et puis, cela promet de belles batailles concernant les sous-titres communautaires de clips musicaux…

Yostral, l’un des piliers de Framalang, a testé le système et publié un journal sur LinuxFr.org que nous reproduisons ici avec son aimable autorisation :

Je viens de tester le site UniversalSubtitles.org, qui se veut le « Wikipédia des sous-titres ».

Le but est simple : faciliter le sous-titrage dans n’importe-quelle langue de n’importe-quelle vidéo se trouvant sur le web.

Voyant les problèmes que nous avons à Framalang pour être efficace en sous-titrage vidéo, chacun faisant une étape dans son coin, sauf la traduction qui se fait sur wiki, pas adapté à ça, j’ai donc fait un petit test sur une simple vidéo, en français, pour voir les possibilité de travail collaboratif de traduction et de sous-titrage.

La première étape consiste bien sûr à « importer » une vidéo. En fait on travaille directement sur une vidéo déjà en ligne. Donc pas d’upload sur le site, pas de transcodage, rien. Il suffit simplement de donner l’adresse de la vidéo souhaitée. Pour le moment, les format supportés sont Ogg, WebM, FLV et donc les sites Youtube et Blip.TV (Dailymotion et Vimeo sont en cours).

Cette vidéo apparaît ensuite dans leur « Widget » de traduction. Une page je suppose remplie de HTML5 et de javascript, qui offre une interface relativement conviviale, claire et avec des raccourcis clavier. C’est succinct, mais suffisant pour faire ce qu’on lui demande. C’est donc ici que se déroule la première des trois étapes qui mènent au sous-titrage original de la vidéo : taper les sous-titres correspondant à la vidéo. Pour ceux qui ont 42 doigts, pas de soucis, vous laissez filer la vidéo et vous entrez le texte en temps réel… pour les autres, on peut toujours faire des pauses et naviguer avant/arrière tout simplement.

La seconde étape est la synchronisation du texte que vous avez tapé précédemment. Là, la vidéo défile et on doit appuyer sur une touche à chaque fois que l’on veut que le sous-titrage passe à la ligne suivante. Ici, faut être concentré ! Bien sûr, on peut mettre en pause, revenir en arrière, mais le mieux est de faire défiler et synchroniser au fur et à mesure. Faisable, mais pas évident, surtout sur la longueur.

La troisième étape est le peaufinage, où on peut ajuster les sous-titres plus précisément. Si on s’est un peu endormi à l’étape précédente, c’est ici qu’on se réveille.

Au final on nous donne un lien permanent vers la vidéo et ses sous-titres, ainsi qu’un bout de code pour l’intégration dans une page web. La vidéo est toujours la même au même endroit et seuls les sous-titres, qu’on peut se télécharger en .srt, sont sur le site d’UniversalSubtitles.org.

À partir de cette page, on peut rajouter simplement des sous-titres dans d’autres langues, calés sur la VO. Ça veut dire qu’une fois la transcription faite et synchronisée, en anglais ou autre, la traduction en français est vraiment simplifiée : on a juste à la rentrer dans les cases en dessous de chaque ligne de sous-titres de la langue originale. On peut bien sûr la stopper puis la reprendre plus tard. On voit également sur cette page les langues disponibles liées à la vidéo et l’avancement des traductions.

Bref, c’est vraiment du sous-titrage collaboratif. Les outils sont minimalistes mais efficaces. On peut tout ré-éditer, sauvegarder, exporter. Et on peut même uploader un fichier .srt, pour ceux qui ont plus souvent l’occasion de traduire hors ligne plutôt que connectés à Internet.

Comme je l’ai déjà dit, les outils sont, pour le moment en tout cas, assez minimalistes. Par exemple on ne peut pas régler les sous-titres : la police, la couleur, l’emplacement… limitation du HTML5 ou pas encore implanté dans ce programme ? On verra. Mais ça risque de poser parfois des gros problèmes de visibilité des sous-titres. Il m’est arrivé à plusieurs reprises, sur les vidéos qu’on a placées sur Framatube, de devoir rajouter une bande noire en-bas, ou les placer en haut, pour pouvoir lire convenablement les sous-titres pour des raisons de contraste avec le fond, qui peut varier…

Un autre bémol, c’est qu’il faut s’enregistrer : il faut soit un compte Twitter, soit un compte OpenID, soit un compte Google… En fait ça ne crée pas de compte à proprement parler, mais se sert de l’existant, ce qui est vraiment un moindre mal.

En tout cas c’est un bel outil qui va nous rendre bien des services pour nos sous-titrages.

Test fait avec une vidéo de Fred Couchet, de l’April, vidéo hébergée sur Blip.tv : http://universalsubtitles.org/videos/JFyBckvaWyCE/fr/

( {"base_state": {"language": "fr"}, "video_url": "http://blip.tv/file/get/Framasoft-FredericCouchetLeRoleDeLAPRILAuxMunicipalesDe2008975.ogv"} )

Que les fans de la première heure se rassurent : la version 4 du célèbre navigateur au panda roux – dont la sortie devrait intervenir d’ici la fin de l’année – promet de recoller au peloton !

Au temps pour ceux qui avaient vendu sa peau un peu trop rapidement : le panda^[1] nouveau met l’accent sur les performances, à commencer par un nouveau moteur JavaScript qui, une fois optimisé, pourrait même lui permettre de prendre la tête de la course si l’on en croit Chris Blizzard (Director of Web Platform chez Mozilla^[2]), dont nous vous proposons ici la traduction de l’interview qu’il a donnée récemment au site derStandard.at (une fois n’est pas coutume, cette traduction a été complétée de références à l’actualité récente avec l’aide de Paul Rouget, Technology Evangelist chez Mozilla).

S’il est difficile de ne pas céder à la mode du benchmarking, on peut toutefois s’interroger sur ce que l’on attend réellement d’un navigateur.

Revenons un instant en arrière : l’irruption de Firefox a permis de réveiller le Web en le libérant de l’hégémonie d’Internet Explorer qui, après avoir éradiqué à peu près toute concurrence sur le marché des navigateurs, n’a plus connu de développement pendant six ans (soit le temps qui sépare la version 6 de la version 7 du navigateur de Microsoft, qui avait même dissout l’équipe de développement dans cet intervalle). Firefox a réussi à propulser le Web vers de nouveaux horizons balisés de standards ouverts propices à l’innovation. Tant et si bien que de redoutables concurrents sont apparus comme Safari d’Apple et surtout Chrome de Google (voir à ce billet du Framablog) et que Microsoft est en train de mettre les bouchées doubles avec son IE 9 pour rattraper son retard.

Faut-il en conclure que Firefox, ayant accompli sa mission, est devenu inutile ?

Il faut en effet reconnaître que le Web ne s’est jamais aussi bien porté qu’aujourd’hui : les concepteurs de navigateurs se battent dorénavant tous pour implémenter les dernières versions des standards ouverts qui sont la base du Web (HTML5, CSS3) quand ils n’en sont tout simplement pas à l’origine. Et pour cela, nous pouvons tous remercier la fondation Mozilla à l’origine de Firefox.

Pourtant, le Web ne se limite pas à des applications riches et jolies devant s’exécuter le plus rapidement possible.

Les grands acteurs du Web, Mozilla mis à part, tirent leurs revenus de l’exploitation de vos données personnelles. La protection de la vie privée devient aujourd’hui un enjeu majeur pour l’utilisateur (qui doit encore en prendre conscience). Mozilla s’apprête à proposer des solutions novatrices dans ce domaine^[3]. Qui d’autre que Mozilla, fondation à but non lucratif, a intérêt à rendre aux utilisateurs le contrôle de leurs données personnelles ? Personne. Et ce n’est pas parce que Apple ou Google (et peut-être un jour Facebook) sort un navigateur performant – fût-il libre (Chromium est la version libre de Google Chrome) – que l’utilisateur jouira des mêmes libertés que l’utilisateur de Firefox, navigateur libre développé par une fondation à but non lucratif.

Firefox 4 : Une génération d’avance en termes de vitesse

Firefox 4: One generation ahead of everyone else speedwise

Andreas Proschofsky – 19 août 2010 – derStandard.at
(Traduction Framalang : Don Rico, Siltaar, Goofy et Antistress)

Chris Blizzard de Mozilla nous parle de la concurrence de Google Chrome, de l’évolution du Web comme plateforme et des attentes que suscite le format WebM.

Ces dernières années Firefox a joué le rôle enviable de l’étoile montante dans le monde des navigateurs. Aujourd’hui, non seulement Google Chrome semble lui avoir volé la vedette mais il vient même lui tailler des croupières. Au cours du dernier GUADEC, Andreas Proschofsky a eu l’occasion de côtoyer Chris Blizzard, « Directeur de plateforme Web » chez Mozilla, et il a réalisé l’interview que vous allez lire, évoquant l’état actuel du marché des navigateurs, les progrès du Web comme plateforme et les améliorations qui arrivent avec Firefox 4+.

derStandard.at : Quand nous avons discuté l’année dernière, vous avez noté que, malgré la notoriété grandissante de Google Chrome, la plupart des développeurs présents dans les conférences techniques – comme le GUADEC – utilisent encore Firefox. Si je jette un coup d’œil autour de moi cette année, les choses semblent avoir considérablement changé : bon nombre de ces utilisateurs avant-gardistes semblent être passés à Chrome / Chromium. Est-ce que vous avez un problème sur ce créneau d’utilisateurs spécifique – mais influent ?

Chris Blizzard : En fait je pense que beaucoup de gens utilisent les deux maintenant, mais c’est vrai que c’est intéressant à voir. De mon point de vue de développeur Web je pense toujours que les outils de Firefox sont de loin supérieurs à ceux des autres.

Il est intéressant de noter que nous n’avons pas vu de changements significatifs dans les statistiques utilisateurs, même si Chrome marque des points importants sur ce segment. Il faut préciser que tous ces chiffres que l’on rapporte sont en réalité des statistiques d’usage et non du nombre d’utilisateurs, si bien que cette avant-garde – qui est grosse utilisatrice du Web – influence les statistiques plus que d’autres, ce qui peut faire croire que Chrome est utilisé par davantage de gens qu’en réalité. Nous avons connu le même effet dans les premiers temps de Firefox, à l’époque nous n’en avions pas conscience faute d’outils adéquats pour le mesurer.

Nous avons aussi effectué quelques recherches et découvert qu’un tas de gens semblent choisir leur navigateur suivant des fonctionnalités particulières. Par exemple beaucoup d’utilisateurs préfèrent retrouver leurs sites récemment visités dès l’ouverture de leur navigateur, donc ils utilisent Chrome. S’ils préfèrent démarrer avec une page vierge, ils utilisent plutôt Firefox. Je pense donc que ce que l’on commence à voir, c’est des gens différents qui veulent faire des choses différentes, et qui vont choisir leur navigateur selon leurs préférences. Et nous n’en sommes qu’au début.

Nous savons que nous ne pourrons pas satisfaire les désirs de tous et ce n’est d’ailleurs pas le but de notre organisation. Nous voulons faire en sorte que le Web devienne une plateforme et nous avons plutôt bien réussi sur ce point.

Google se lance maintenant dans un cycle de développement visant à offrir une nouvelle mise à jour stable toutes les six semaines, pour essayer de proposer des innovations plus rapidement aux utilisateurs. Mozilla, de son côté, publie au mieux une nouvelle version par an : cela n’est-il pas handicapant d’un point de vue marketing ?

Cela dépend du rythme que vous voulez adopter. Les gens de Chrome ont une approche un petit peu différente de la nôtre. Il va être intéressant de voir si d’autres utilisateurs que les avant-gardistes seront d’accord pour voir leur navigateur changer tous les mois et demi. Nous préférons prendre davantage de temps pour préparer les gens à des changements d’interface plus importants.

Pour autant nous ne modifions pas toujours le numéro de version pour les gros changements. Citons par exemple l’isolation des plugins que nous avons récemment ajoutée à la série 3.6.x, qui résulte d’un énorme travail et qui a grandement amélioré l’expérience des utilisateurs de Firefox.

À vrai dire, je suis quelque peu sceptique à l’idée d’un cycle de six semaines. Comment peut-on vraiment innover en un laps de temps si court ? Accélérer la cadence est néanmoins dans nos projets, il faut juste que nous trouvions celle qui nous convient.

Un des avantages d’un cycle de publication rapide, c’est que Google peut diffuser très vite des fonctionnalités comme le futur web-store de Chrome. Aimeriez-vous aussi proposer une plateforme de téléchargement d’applications Web chez Mozilla ?

En ce qui me concerne, je pense qu’un app-store pour le Web est une idée intéressante, car en gros cela rend les applications Web plus accessibles et fournit un modèle de monétisation. Mais pour bien faire, il faut tenir compte de nombreux autres paramètres, et c’est là-dessus que nous allons d’abord nous concentrer.

Quels éléments manque-t-il encore pour concevoir un bon web-store ?

Les performances Javascript sont très importantes, mais nous touchons au but, car nous sommes en passe d’obtenir les mêmes performances que les applications exécutées nativement. Vient ensuite le webGL pour les applications en 3D, et nous devons aussi régler la question du stockage de données hors-connexion qui est loin d’être abouti pour le moment. Il faut aussi accorder une grande importance à la sécurité, question sur laquelle nous sommes justement en train de travailler. Par exemple, grâce à la fonctionnalité ForceHTTPS, un site Web pourra dire à un navigateur de ne communiquer avec lui que par données chiffrées, ce qui préviendra certains types d’attaques. Nous nous penchons aussi sur la politique de sécurité des contenus, ce qui sera très utile pour lutter contre une catégorie entière d’attaques type cross-site scripting (NdT : citons par exemple la fonctionnalité X-FRAME récemment introduite contre le clickjacking).

Dans les tests de performances Javascript récents, Firefox semble avoir dégringolé dans le bas du classement, et se place même derrière Internet Explorer 9. N’arrivez-vous plus à suivre ?

Firefox 4 apportera de nombreuses améliorations dans ce domaine-là aussi, mais elles ne sont pas encore intégrées à nos versions de développement. Nous avons constaté que, lorsque notre Tracing-Engine (NdT : moteur basé sur la technologie du tracé) est utilisé, nous sommes plus rapides que tous les autres. Nous ne sommes à la traîne que dans les cas où cette technologie ne peut être exploitée. Nous travaillons donc à améliorer les performances de base de notre moteur JavaScript, qui, combinées à l’optimisation JIT Tracing , nous donneront une génération d’avance sur tout le monde (NdT : Jägermonkey, le résultat de ce travail, vient d’être intégré à la version de développement de Firefox 4).

La vérité c’est que la marge d’amélioration est encore énorme. La génération actuelle des moteurs Javascript a atteint un palier : en pourcentage, les différences que nous constatons entre les différents navigateurs sont infimes. En outre, les tests de performance ne sont plus d’une grande utilité, car, pour la plupart, ces chiffres ne sont plus influencés par les performances Javascript réelles. Voici un exemple des conséquences négatives des tests de performance : nous avons dû fournir des efforts particuliers sur l’optimisation du calcul de décalage horaire car cela influe négativement certains tests de performance, mais ça n’améliore pas réellement les performances Javascript. Sunspider est affecté par ces problèmes et V8 contient aussi du code bancal, il est donc difficile de trouver de bons tests de performance (NdT : Mozilla vient de lancer Kraken, un test censé mesurer les performances JavaScript en situation réelle).

Firefox 4 va utiliser l’accélération matérielle grâce à Direct2D et à DirectWrite sous Windows. Des fonctionnalités similaires sont-elles prévues pour Linux et Mac OS X ?

Dans la limite des outils qui sont disponibles, oui. Nous essayons de procurer aux utilisateurs la meilleure expérience possible sur chaque plateforme. Pour Windows Vista et 7 nous constatons d’immenses améliorations lorsque le navigateur doit réaliser des tâches graphiques intensives. Sur OS X, par exemple, nous prenons en charge l’OpenGL pour la composition d’images, et nous faisons de même sous Linux. Mais en général les API dont nous disposons sous Windows sont meilleures et plus riches que sur les autres plateformes. Sous Linux, Cairo et Pixman étaient censées être rapides, mais hélas l’infrastructure sur lesquelles elles reposent n’a jamais vraiment atteint la vélocité désirée. Sur OS X, Firefox est assez rapide, mais pour l’instant Direct2D confère l’avantage à la version Windows (NdT : plus d’informations sur cet article de Paul Rouget).

L’isolation des plugins devait n’être que la première étape d’un Firefox multi-processus, avec un processus séparé pour chaque onglet. C’est un des gros morceaux du cahier des charges de Firefox 4. C’est toujours prévu ?

Bien sûr, mais pas pour Firefox 4. Ce sera sans doute disponible pour la version mobile avant la version desktop. C’est intéressant de constater que c’est plus facile sur cette plateforme.

Il y a peu, vous avez endossé le rôle de « Directeur de plateforme Web » chez Mozilla. En quoi cela affecte-il vos responsabilités quotidiennes ?

Auparavant, je me chargeais essentiellement de diriger les groupes d’évangélisation et de communication, mais j’ai fini par travailler de plus en plus sur les questions de plateforme Web – réfléchir à l’avenir du Web, discuter régulièrement avec les autres concepteurs de navigateurs. Tout cela a pris une telle importance que j’ai décidé de m’y consacrer à plein temps.

Par exemple, je viens de participer à une réunion de l’IETF, où nous avons eu des discussions très riches sur le http, les websockets, et aussi sur les codecs. Ils sont en train de mettre au point un codec audio de nouvelle génération pour les communications en temps réel et s’appuient sur l’IETF pour les spécifications. En gros, c’est une combinaison de techniques existantes, et l’accent est mis sur une latence très basse, un domaine où le Vorbis ou le MP3 sont mauvais. Ce travail s’effectue en collaboration avec Skype.

Une des grosses annonces de ces derniers mois concernait la création du WebM comme nouveau format vidéo ouvert basé sur le VP8 et Vorbis. Pensez-vous que ses chances de réussites soient meilleures que celles de Theora ?

Oui, pour des raisons de qualité. Quelques explications : il est bon de savoir que lorsqu’on utilise le H.264, on doit en gros choisir un des trois profils que propose ce codec. En général, les sites vidéos doivent offrir la version basique car c’est la seule prise en compte par l’iPhone, notamment dans ses anciennes versions qui sont utilisées par des dizaines de millions de personnes. Donc, si l’on compare les formats vidéo, il faut comparer le VP8 au H.264 « basique », et ce n’est pas qu’une manœuvre réthorique, c’est la réalité pour tous les services. J’ai discuté avec les gens de YouTube, par exemple : ils ont essayé d’utiliser un autre profil du H.264, mais ils ont dû revenir au « basique » à cause du manque de prise en charge. Sur cette base, la question de la qualité n’a plus lieu d’être, et le VP8 est tout à fait compétitif.

Si l’on parle de l’implémentation de la balise vidéo HTML5, il faut aussi prendre en compte l’évolution du marché. Si l’on envisage un monde où la vidéo HTML5 est répandue dans la majorité des navigateurs – par-là je pense à une proportion de 80%, ce qui devrait être le cas d’ici deux ans –, il faut compter avec les tendances et les changements dans les parts de marché des systèmes d’exploitation. On se rend alors compte qu’on se retrouve avec un marché segmenté. Ceux qui voudront diffuser de la vidéo devront prendre en charge à la fois H.264 et WebM. Sur le long terme, je suis certain que les codecs libres sont en meilleure posture, surtout si l’on prend en considération les tendances à venir comme les communications en temps réel ou les plateformes mobiles, où WebM est très performant – ou va l’être grâce à des partenariats avec des constructeurs de matériel.

Firefox 4 va permettre de construire des extensions « poids plume » sous forme de Jetpacks. Quand vont-ils remplacer la génération actuelle d’extensions ?

Les Jetpacks ne sont pas conçus pour remplacer les extensions XUL. Firefox est une plateforme que l’on peut étoffer à l’envi grâce à une large palette d’interfaces. On peut aussi modifier beaucoup de choses dans les paramètres mêmes de Firefox, ce qu’aucun autre navigateur ne permet. Comme projet, c’est extraordinaire : une grand part de nos innovations sont arrivées par les extensions avant d’intégrer directement le navigateur.

Pour nous, les Jetpacks sont grosso modo un équivalent des extensions pour Chrome, qui offrent beaucoup moins de possibilités que nos extensions XUL classiques. Ils seront néanmoins beaucoup plus faciles à réaliser. Nous allons fournir un éditeur en ligne qui facilitera leur développement. Ces Jetpacks seront aussi plus faciles à tester, et l’on pourra les installer sans avoir à redémarrer le navigateur. Ce qui est d’ailleurs déjà possible avec certaines extensions XUL dans Firefox 4, à condition que cela soit signalé et que l’extensions soit codée avec soin.

Lors de la dernière Ubuntu Party à Paris, les framalinguistes ont lancé avec succès le premier « Traducthon ». Ce coup d’essai réussi ne pouvant rester orphelin, Framalang relève son propre gant. La deuxième édition du Traducthon (ou Traducthon 2.0) aura donc lieu du 6 au 9 juillet prochain à Bordeaux au cours des fameuses et célèbres Rencontres Mondiales du Logiciel Libre^[1].

L’ambition est cette fois plus grande. La gourmandise des framalinguistes n’ayant pas de limite, nous ne pouvions donc nous limiter à un article. 4 jours d’intenses traductions, relectures, reformulations, mise en page, bières s’offrent à nous. Le texte sélectionné se devait donc d’être à la hauteur.

Le choix de Framalang s’est porté sur un livre au cœur de l’actualité : Imagine there is no copyright and no cultural conglomerates too / An essay (ce qui donne en français et en chantonnant du John Lennon : Imaginez qu’il n’y ait ni droit d’auteur ni industrie culturelle / un essai).

Ce document des néerlandais Joost Smiers et Marieke Van Schijndel analyse dans le détail les raisons du déclin du droit d’auteurs tel qu’il a été conçu à une époque d’avant l’immatériel, et pourquoi il ne peut survivre à l’univers numérique dont la présence est croissante dans nos vies quotidiennes. Cet essai propose par ailleurs un certain nombre de pistes, permettant de transformer le marché hyper-dominé de l’industrie culturelle en marché de micro-entrepreneurs de cette même culture, permettant une ouverture maximale du marché, en libérant les créateurs et en leur permettant de se rapprocher de leur public.

When a limited number of conglomerates control our common area of cultural communication to a substantial degree, then that undermines democracy. The freedom to communicate for everyone and everyone’s right to participate in his or her society’s cultural life, as promised in the Universal Declaration of Human Rights, can become diluted to the unique right of a few heads of companies and investors and the ideological and economic agendas to which they work.

Ce qui pourrait se traduire par :

Lorsqu’un nombre réduit de groupes industriels contrôle à un certain point notre univers commun de communication culturelle, il sape alors la démocratie. La liberté de chacun de communiquer et le droit de chacun de participer à la vie culturelle de sa propre société, tels que promis par la Déclaration Universelle des Droits de l’Homme, peuvent se trouver dilués dans le droit unique de quelques dirigeants d’entreprises ou de quelques investisseurs, et dans les priorités idéologiques et économiques pour lesquelles ils travaillent.

Tous ceux qui le souhaitent peuvent participer à cette aventure avec nous. La traduction aura lieu sur le Pad de Framasoft. L’exercice de la traduction nécessite des compétences aussi variées que la maîtrise de l’anglais, la capacité de reformulation ou celle d’assurer la cohérence du style, une relecture attentive, mais surtout une grande ouverture d’esprit.

Toutes les bonnes volontés sont donc les bienvenues, sur place ou à distance. Et, as usual, dans la joie et dans la bonne humeur 😉

Comme vous le savez, HTML5 est la cinquième version du langage utilisé pour concevoir les pages Web, qui propose enfin aux développeurs le moyen d’afficher directement et simplement les vidéos dans la page, de la même façon qu’il est déjà possible de le faire pour des images. C’est à dire de façon simple, ouverte et puissante, sans la contrainte de recourir à un plugin propriétaire comme Flash.

Mais la taille des vidéos doit être réduite pour pouvoir être diffusées sur Internet, et comme il a déjà été dit dans ces colonnes, HTML5 est muet quant au format à utiliser pour compresser ces vidéos (on parle aussi de codec). Aujourd’hui, deux codecs peuvent techniquement assumer ce rôle clé : Theora et H264 (en attendant une possible libération du codec VP8 racheté par Google). Mais alors que le premier est entièrement libre et utilisable sans aucune restriction, le deuxième est breveté et son usage est rigoureusement encadré et soumis à redevance.

On comprend alors que l’affrontement de ces deux codecs n’est que la traduction de l’affrontement de deux visions : tandis que Theora doit permettre de maintenir un Web ouvert où chacun serait libre de publier du contenu ou de créer des applications innovantes, H264 permettra à quelques entreprises privées de faire main basse sur le Web.

À côté de l’avènement de HTML5, un autre facteur est en train de rebattre les cartes : il s’agit du nombre grandissant d’appareils mobiles reliés à Internet^[1].

Pour ces appareils mobiles, la question de la puissance processeur et de la consommation électrique se pose de manière nouvelle : ces appareils sacrifient souvent la première au profit de la seconde.

Ainsi, à l’inverse de ce qui se passe dans le monde des micro-ordinateurs de bureau, où l’architecture x86 développée par Intel domine, l’univers des appareils ultra mobiles est dominé par une architecture concurrente : ARM.

Les processeurs ARM (pour Advanced Risc Machine) sont des processeurs fabriqués sous licence par différentes sociétés de par le monde à partir des travaux de la société anglaise ARM. Cette société conçoit des processeurs consommant peu d’énergie qui se retrouvent ensuite dans la plupart des appareils mobiles : des sociétés comme Nokia, Google (Nexus One), HTC, Samsung, Apple (Iphone/iPad), Sony Ericsson, Palm (Plam Pre), Siemens, LG, ou encore Motorola l’utilisent dans leurs smartphones.

Dans la mesure où l’on retrouve souvent le codec H264 dans les vidéos en Flash et où le format H264 exige d’importantes ressources processeur pour être décodé, de nombreux appareils mobiles ont été optimisés pour aider au décodage du H264.

De fait, ce handicap initial est devenu paradoxalement un avantage pour le H264 : bien que Theora demande beaucoup moins de ressources pour être décodé et soit ainsi plus adapté aux appareils mobiles, certains lui opposent le fait qu’il ne bénéficie pas du même support matériel que le H264.

Heureusement la situation n’est pas figée et de nombreux développeurs sont à pied d’œuvre pour permettre à Theora de tirer parti de ces optimisations matérielles (en attendant que les fabricants implémentent eux-même leurs optimisations pour Theora).

C’est le cas notamment de Google qui investit dans le développement de theorARM, une version de Theora optimisée pour les processeurs ARM, comme l’explique Robin Watts sur le blog « des projets Open Source » de Google dans le billet traduit ci-après.

Avant de laisser la parole à Robin Watts, remarquons que, depuis que Theora est pressenti comme codec possible pour la vidéo sur le Web, celui-ci s’améliore de manière constante. Tous les défauts relevés à l’encontre de Theora sont en passe d’être corrigés grâce aux efforts conjugués de toute une communauté de développeurs talentueux regroupée derrière la fondation Xiph.Org (qui développe Theora) dont Red Hat, les fondations à but non lucratif Wikimédia et Mozilla, et à présent Google.

H264, de son côté, reste irrémédiablement entravé par son péché originel : celui d’être breveté jusqu’à l’os. Et les meilleurs développeurs du monde n’y pourront rien changer.

Bref, là où Theora promet le meilleur, à tous points de vue, H264 n’annonce que le pire.

Ça bouge du côté de la vidéo sur le Web

Interesting times for Video on the Web

Robin Watts – 9 avril 2010 – Google Open Source Blog (Traduction Framalang : Olivier Rosseler et Goofy)

Si je vous disais que Google a participé au financement d’une version du codec Theora optimisée pour les processeurs ARM, vous seriez nombreux à passer directement au billet suivant de ce blog. Personne ne se soucie des codecs audio ou vidéo, du moins tant qu’ils fonctionnent.

Demandez à la plupart des utilisateurs d’ordinateurs quel est leur codec favori et ils vous regarderont comme si vous aviez demandé leur moteur de machine à laver préféré. « On veut juste que ça marche ! » vous répondront-ils. C’est exactement la même chose pour ceux qui créent et publient du contenu sur le Web. À chaque fois qu’une vidéo est inaccessible au visiteur d’un site Web, c’est un message qui n’atteint pas sa cible. Peu importe la qualité du message et le temps passé à le peaufiner, ou les techniques virales employées pour attirer les visiteurs ; si la page Web n’affiche qu’un beau rectangle vide à l’endroit du contenu, tous ces efforts auront été vains.

Publiez la vidéo afin qu’elle soit lisible partout

L’idée est bonne, mais sa mise en pratique est loin d’être simple. Il n’existe aucun standard vidéo actuellement sur le Web. Certains sites utilisent la technologie Flash, restreignant ainsi leur auditoire aux utilisateurs disposant d’un lecteur Flash et excluant de fait la plupart des téléphones. Certains se servent de lecteurs Java intégrés, mais l’auditoire se limite alors au seul public disposant de machines suffisamment puissantes pour décoder l’audio et la vidéo dans une machine virtuelle, ce qui exclut tout ce qui est plus lent qu’un ordinateur portable. D’autres encore se reposent sur les lecteurs natifs à telle plateforme (comme Windows Media Player) et se coupent ainsi de toutes les autres plateformes. D’autres enfin ne proposent que le lien vers la vidéo et s’en remettent au lecteur vidéo que l’utilisateur a pu éventuellement installer.

On est bien loin du « ça marche, tout simplement », et aucune de ces solutions ne semble en prendre le chemin. Que ça vous plaise ou non, avec la multiplication des appareils connectés, ce Graal va être de plus en plus difficile à atteindre. À une époque, il suffisait de s’assurer que la vidéo était lisible sur PC et sur Mac. Maintenant il faut jongler entre Android, ChromeOS, iPhoneOS, Linux, Maemo, Symbian et plein d’autres systèmes encore. Et ce n’est pas tout, puisqu’il faut prendre en compte toute une gamme de processeurs de puissances différentes, depuis les ordinateurs de bureaux aux téléphones en passant par les ordinateurs portables, les netbooks et les PDA. Le problème est loin d’être résolu, bien au contraire.

Heureusement, HTML5 nous apporte de l’espoir. Cette nouvelle version d’HTML (le langage de base utilisé pour écrire les pages Web) introduit un élément video.

Un standard existe maintenant pour que les gens spécifient dans le code de la page l’intégration d’une vidéo. À chaque navigateur, ensuite, d’implémenter la lecture des vidéos : soit qu’il lise lui-même la vidéo soit qu’il délègue cette tâche à un lecteur incorporé ou externe. Dans tous les cas, la décision appartient à l’utilisateur au lieu d’être imposée par le créateur du contenu. Le plus génial dans tout cela, c’est que cette fonction est déjà supportée : Firefox, Opera, Chrome et Safari prennent déjà en charge le HTML5 et les autres navigateurs suivront rapidement.

Alors, problème réglé ?

À vrai dire, non. Il existe désormais un langage commun pour publier des vidéos, c’est un bon début, mais la question du format n’est pas résolue. Là, il n’y a pas de « taille unique ». La vidéo est-elle visionnée sur un téléphone avec un petit écran, sur un netbook, sur un PC de bureau, ou sur un écran LED 3D de 150 pouces à la résolution quatre fois supérieure à celle de la TVHD ? La taille de l’écran, la connectique et la puissance de calcul jouent chacune un rôle ici. Un peu comme la transition de la VHS au DVD puis au BluRay pour les vidéos télévisées, la vidéo sur le Web va s’améliorer au fur et à mesure. Et c’est très bien ainsi : la technologie des serveurs Web permet d’adapter la vidéo au navigateur et à l’appareil utilisés.

En revanche, il nous faut assurément nous accorder sur un plus petit dénominateur commun, un format standard qui servira de format par défaut si tout le reste échoue. Ça ne doit pas nécessairement être le format le plus complexe, ou le plus marketé, ni même celui créé par l’union du plus grand nombre d’entreprises. Il doit simplement être disponible, partout. Le codec le plus adapté actuellement est Ogg Theora, dérivé du codec VP3 libéré par On2 il y a quelques années. Il se débrouille plutôt bien en termes de qualité et de compression, et il n’a pas à rougir face à ses rivaux plus populaires comme le MPEG4, tout en étant bien plus simple à décoder. Mais surtout, il se démarque de ses concurrents par le fait qu’il est libre. Vraiment libre. Pas seulement « libre d’utilisation dans les décodeurs » ou « libre d’utilisation si vous signez cet accord de licence compliqué », mais vraiment, honnêtement, authentiquement, 100% libre. Les spécifications du flux et le code source de l’encodeur/décodeur sont accessibles publiquement et peuvent être librement utilisées/modifiées par n’importe qui. Theora a toujours été développé avec comme objectif premier d’éviter les brevets. Aucun autre codec que Theora ne peut se targuer de n’enfreindre aucun brevet et de n’être soumis à aucune redevance tout en tenant malgré tout la dragée haute à ses concurrents.

Alors, qu’est-ce qu’on attend ?

Décoder une vidéo demande beaucoup de ressources au processeur. Un important travail reste à accomplir avant de réaliser le rêve de lire une vidéo sur n’importe quel appareil. Theora est bien moins complexe que bon nombre de ses concurrents : les autres codecs nécessitent souvent du matériel dédié pour atteindre des performances décentes, alors que, bien programmé, Theora peut être décodé sans aide extérieure. En fait, sur les ordinateurs portables ou de bureau, le décodage à la volée est possible dans un lecteur Java intégré (comme par exemple l’excellent Cortado, lui aussi libre), ce qui permet la lecture de vidéos dans les navigateurs ne prenant pas encore en compte l’élément video. Mais ça n’est pas envisageable pour les appareils comme les PDA, les téléphones, les netbooks, les tablettes ou les lecteurs portables. Ces engins reposent souvent sur des processeurs ARM qui sont bien moins énergivores que les processeurs qui équipent habituellement les micro-ordinateurs. Malgré les gains de puissance continus réalisés au cours de ces dernières années, ils ne rivalisent pas encore avec leurs cousins plus costauds pour ce qui est de la puissance pure. Cette gamme très importante d’appareils construits autour de processeurs ARM représente le dernier défi pour un décodage fluide de Theora. Tout progrès d’efficacité réalisé se traduit par davantage d’autonomie ou des écrans plus grands.

C’est là que l’aide financière de Google intervient. En subventionnant le développement de TheorARM (une version libre de Theora optimisée pour les processeurs ARM), ils nous aident à nous rapprocher du jour où la vidéo fonctionnera partout sur le Web, pour tout le monde. Ça serait plutôt pas mal, non ? Ça y est, maintenant vous pouvez passer au billet suivant du blog.