WebM, un nouveau prétendant pour le HTML5

Arnaud de la Grandière |
Alors que Google vient de présenter WebM, un nouveau format libre de vidéo basé sur le codec VP8 dont elle avait fait l'acquisition en rachetant On2, Jason Garnett-Glaser, un développeur qui travaille notamment sur x264, une implémentation libre du codec H.264, s'est penché sur la documentation du nouveau standard libre pour en livrer son analyse.

Spécifications et implémentations

Commençons par nous attarder sur la notion de format de fichier. Dans les formats ouverts et offerts à la communauté de développeurs, on trouve deux catégories : d'une part les spécifications, et de l'autre les implémentations. En faisant une métaphore culinaire, si vous voulez utiliser une "sauce" donnée pour votre plat, les spécifications sont la recette de la sauce, et les implémentations ce sont des sauces prêtes à utiliser telles quelles.

Les spécifications d'un format de fichier sont données dans un document qui se veut le plus "agnostique" possible en matière de langage de programmation. Elles expliquent par le menu le format en lui-même, en langage le plus clair possible : les en-têtes, la manière dont les données sont éventuellement encodées, structurées et stockées, sur quel nombre d'octets, etc. De telle manière qu'un programmeur pourrait théoriquement être à même de "lire manuellement" le contenu d'un fichier rien qu'en regardant les données binaires.

D'autre part, les implémentations sont des bibliothèques de code toutes prêtes qui permettent de lire et/ou d'écrire un fichier dans le format en question, dans différents langages de programmation. Il suffit d'importer ces bibliothèques dans un programme du même langage pour exploiter le format de fichier en question. Naturellement, les implémentations ne sont utiles que lorsque le langage de programmation qui a été choisi pour faire un logiciel est couvert par ces implémentations.

En résumé, si les implémentations sont les plus pratiques pour peu qu'elles exploitent votre langage de prédilection, les spécifications en revanche sont les plus importantes dans la mesure où elles donnent aux programmeurs le moyen d'utiliser le format de fichier dans n'importe quel langage, y compris dans ceux qui ne sont pas couverts par les implémentations. Les spécifications permettent donc aux développeurs d'être autonomes.

Pour un format donné, on peut donc trouver de bonnes et de mauvaises implémentations, et de bonnes et de mauvaises spécifications. Raison pour laquelle un très bon encodeur MPEG-1 peut s'avérer plus efficace qu'un très mauvais encodeur H.264 par exemple. C'est également là où les spécifications sont importantes, car elles permettent de créer des implémentations plus efficaces du format de fichier que celles qui sont fournies, y compris dans le même langage.

Car il faut noter, concernant les formats de fichiers vidéo, que ceux-ci sont intimement liés à la façon dont on compresse et décompresse les données avant de les stocker : les codecs vont souvent de pair avec les formats de fichier vidéo, comme c'est le cas pour les différentes versions du MPEG par exemple.

Mais pour compliquer un peu plus les choses, certains formats, comme le mov, l'avi ou le matroska (du nom des poupées russes), sont des métaformats qui peuvent inclure plusieurs pistes compressées avec n'importe quel codec. Le format de fichier que Google a choisi est le matroska, un format de vidéo libre renommé WebM par Google, qui inclut donc une piste vidéo encodée en VP8, et une piste audio encodée en Open Vorbis. On a donc un format dans le format. Concernant le format de fichier en lui-même, il ne pose pas de problème particulier et est même plus efficace que le MP4 pour le streaming. Quant à Vorbis, c'est le format audio ouvert qui est le plus sensé, sachant qu'il fait quasiment jeu égal avec l'AAC, exception faite des taux de compression les plus élevés.

Un lancement trop hâtif ?

Et concernant VP8, le moins que l'on puisse dire c'est que les spécifications ont de quoi faire pâlir : il ne s'agit, pour l'essentiel, de rien de moins qu'un copier-coller du code source de l'implémentation du codec en C… y compris les astuces pour améliorer l'efficacité du code par rapport au langage en lui-même, les commentaires marqués "à faire", des parties absconses et mal expliquées, bref, si vous voulez faire votre "sauce", il vous faudra déduire ses ingrédients et sa conception en la goûtant… En somme, l'implémentation tient lieu de spécification : au lieu de donner la recette, accessible à tous, on ne donne que la sauce préparée, qui n'est accessible qu'aux palais les plus fins. Mais pire encore, sachant que les spécifications sont déclarées finales et non modifiables, il est donc impossible de les corriger et/ou de les améliorer. Google a d'ores et déjà refusé les amendements qui lui ont été soumis, et à moins de lancer un nouveau profil pour le VP8, il faudra donc faire avec les bugs que le codec recèle…

Mais ce problème est loin d'être un cas unique : en effet, le standard H.264 intègre diverses fonctionnalités, qui sont réparties sur différents "profils" en fonction des applications qu'on souhaite faire du codec. L'iPhone, l'iPod touch et l'iPad ne gèrent que le profil "baseline" du standard et non ses implémentations plus performantes. Moralité c'est un nivellement par le bas pour qui tient à proposer des vidéos compatibles avec ces appareils. Le Blu-ray connait également la même problématique avec certains lecteurs de première génération.

Quoi qu'il en soit, pour en revenir aux spécifications de VP8, d'un point de vue d'ingénieur, le constat est amer, et on se trouve typiquement face à un cas de "ni fait ni à faire", fort surprenant venant des troupes d'élite de Google. Il semble que le tout a été clairement bâclé pour être mis à disposition maintenant, vaille que vaille. Il est vrai que la fenêtre de tir pour le VP8 est déjà très restreinte : il s'agit de faire mieux qu'Ogg Theora en reprenant tout de zéro alors que le H.264 règne en maître dans le monde de la vidéo, aussi bien sur le marché professionnel que grand public. Google pouvait donc difficilement se payer le luxe de prendre son temps, mais n'ajoute-t-elle pas là un écueil de plus dans un contexte déjà très délicat pour ce codec ?

Mieux que Theora, moins bien que H.264

Les problèmes ne s'arrêtent d'ailleurs pas aux seules spécifications de VP8. Selon Jason Garrett-Glaser, VP8 est comparable dans ses principes au profil Baseline du H.264. D'après lui, il paraît impensable que le format ne s'attire aucun procès pour violation de brevet dans les pays qui ont institué les brevets logiciels. La chose n'a à vrai dire rien de surprenant, à tel point qu'on pourrait l'ériger en axiome : à mesure que la complexité d'un procédé augmente, la probabilité que certains éléments constitutifs du procédé en question soient déjà brevetés s'approche de 1.

C'est d'ailleurs un argument qui a été soulevé plusieurs fois : pour certains il paraît impossible de créer un codec vidéo libre qui ne soit pas couvert par des brevets. En partant de ce principe, les logiciels libres devront rester cantonnés au tout-venant dans les pays où les brevets logiciels sont institués (à moins de développer une science de la simplicité, qui a tout de même quelques vertus).

Garret-Glaser considère que VP8 est légèrement meilleur que le profil Baseline du H.264 en termes de fonctionnalités, mais loin derrière les profils Main et High Profile du standard ouvert. Au niveau de l'encodage, il situe la qualité visuelle entre le Xvid et le VC-1 de Microsoft, ce qui est très honnête. Le décodage est en revanche plus lent que l'implémentation du H.264 qu'on trouve dans FFMPEG. Par contre, il s'agit clairement d'une amélioration par rapport à Ogg Theora ou à Dirac. En somme, VP8 partage certains problèmes avec l'Ogg Theora du point de vue des brevets et de l'absence d'accélération matérielle, mais il propose une amélioration notable dans le rapport qualité/compression.

John Gruber souligne d'ailleurs narquoisement que Christopher Blizzard, évangéliste de Mozilla, disait il y a quatre mois que "la plupart des gens ne peuvent pas voir de différence entre une vidéo encodée avec un encodeur Theora décent et une vidéo encodée avec H.264", et aujourd'hui que "le codec VP8 représente une grande amélioration de qualité-par-bit vis-à-vis de Theora, et est comparable en qualité avec le H.264"…

Qui m'aime me suive

Pour l'heure, Google, la Fondation Mozilla et Opera ont fait savoir que leurs navigateurs respectifs allaient intégrer le support de ce codec, en plus de ce qu'ils intègrent déjà (Chrome gère aussi bien le H.264 qu'Ogg Theora, tandis qu'Opera et Firefox ne gèrent qu'Ogg Theora).

operawebm
Un prototype d'Opera compatible WebM


Microsoft quant à elle a donné une réponse savamment formulée : concernant Internet Explorer 9, le navigateur permettra la lecture de fichiers au format WebM… dans la mesure où l'utilisateur aura installé le codec par ailleurs. En somme, si IE 9 permettra la lecture de vidéos H.264 en standard, il n'en sera pas de même pour WebM. Plus que le supporter, Microsoft permet donc d'utiliser WebM en ne l'interdisant pas…

Même réponse de Normand concernant Silverlight : si le plugin concurrent de Flash gère nativement en standard des codecs tels que H.264, VC-1, WMA, MP3, et AAC, il permet également aux développeurs de créer leurs propres implémentations d'un codec à l'aide de la fonctionnalité de gestion de flux AV bruts. Ainsi, les programmes réalisés pour Silverlight ont pu intégrer des codecs "maison" pour MPEG4.2, Ogg Theora et autres, mis au point par des développeurs de tierce partie. Il sera donc possible d'implémenter WebM dans Silverlight, mais Microsoft ne fournira pas le support natif au sein de son plugin : à charge de chacun de s'en occuper.

Adobe de son côté a fait savoir que le format serait géré par le plugin Flash à l'avenir, ce qui lui donne de meilleures chances qu'Ogg Theora : ainsi, si un navigateur ne peut lire nativement du H.264, il reste possible de lire ce format via un fichier Flash, et il sera possible d'en faire autant à l'avenir avec des vidéos au format WebM.

Reste la question de l'accélération matérielle, qui manque aussi cruellement à WebM qu'à Theora. Google a tout intérêt, notamment pour sa plateforme Android, à encourager la mise au point de puces qui gèrent ce codec, et différents constructeurs (AMD, ARM, Broadcom et NVIDIA) ont annoncé soutenir le projet et apporter une accélération matérielle, mais tant que ça ne sera pas le cas et qu'aucun matériel ne gérera nativement ce format, il n'y a guère d'espoir de le voir décoller en termes de popularité face à l'omniprésent H.264.

Google a indiqué que YouTube allait faire usage de ce format, et celui-ci ne manque pas de bonnes fées autour de son berceau. Google a répondu à l'appel de la Free Software Foundation (lire La FSF enjoint Google à libérer le codec VP8), reste à voir si la stratégie sera payante et suffisante pour inverser la vapeur. Dieu sait qu'il faudra toute l'aide dont WebM pourra disposer pour espérer rattraper le H.264, qui a pris énormément d'avance en terme de popularité.

En somme, le projet est encore en devenir, et il n'est pas sans inconvénient. Il reste beaucoup à faire pour que WebM soit une alternative sérieuse face au H.264, et il faut également souligner que son avènement affaiblit les chances d'Ogg Theora, déjà maigres. Car VP8 ne vient en rien remplacer Ogg Theora, qui continuera de coexister avec lui. Certes, d'un point de vue technologique et à contraintes égales, WebM est préférable à Theora, et fait donc figure de choix logique pour les nouvelles implémentations, mais ça n'empêche pas ce dernier d'être déjà utilisé et supporté. Moralité, les acteurs du marché auront désormais le choix entre trois formats au lieu de deux, augmentant la cacophonie. De son côté, H.264 reste l'unique candidat propriétaire, alors que la multiplication de formats libres ne fait que diluer leur influence potentielle, outre les problèmes inhérents à leur nature.
avatar Ziflame | 
En clair, Google, pour conserver son aura de « gentil » sort un truc pourrave, mais limite presque bien et laisse « le marché » décider. Le marché, qui est moins bête que les idéologues libristes, décidera h.264, Google supporte le h.264 et ils diront « Vous ne pouvez pas dire que nous n'avons pas tout essayé. ». Je me demande pourquoi les Européens s'enflamment tellement pour ce débat tellement américano-centriste. Les brevets logiciels n'ont aucune valeur chez nous. Arrêtons de jouer aux pleureuses, ce débat ne nous concerne pas. Choisir le meilleur idéologiquement au profit du meilleur technologiquement n'est jamais très malin, sur le long terme.
avatar gl3am | 
C'est une petite bombe que viennent de lancer Google, Mozilla et Opéra ! Que va faire Apple ?
avatar Anonyme (non vérifié) | 
[quote]Certes, d'un point de vue technologique et à contraintes égales, WebM est préférable à Theora, et fait donc figure de choix logique pour les nouvelles implémentations, mais ça n'empêche pas ce dernier d'être déjà utilisé et supporté.[/quote] Par qui ? Personne à part quelques libristes militants et quelques expérimentations mais rien de sérieux et de définitif. Tout le monde savait que Theora ne servait à rien, il en va tout autrement de VP8 grâce à son support par Flash qui permettra donc la compatibilité cross-browser, tout comme ce qu'on à avec H264. Sauf qu'au lieu que le natif soit Safari + Chrome et Flash pour les autres, on aura natif pour Firefox + Chrome + Opera et Flash pour les autres. En regard des parts de marché c'est vite vu : VP8 est plus intéressant. Surtout que Safari exploitant les codecs QuickTime et IE9 ceux de WMP visiblement, on pourra avoir VP8 partout avec le plugin qui va bien alors que FF ne supportant pas les codecs du système, on ne pouvait pas lui faire lire H264 même si l'OS disposait des codecs. L'avenir est donc au VP8, Theora on s'en fiche pas mal et H264... sera peut-être un format à conserver pour l'iPhone/iPad si Apple rejette ce codec, ce qui risque fort d'arriver. Auquel cas on se retrouvera exactement dans la même situation que l'actuelle qui force un double encodage, mais avec une meilleure qualité pour VP8, et avec IE9 qui arrive on pourra avoir des vidéos sans Flash si on accepte de doubler l'occupation de l'espace disque du serveur. Ca commence à être envisageable.
avatar amnesique | 
il y a une chose que je n'ai pas saisi.. Si x264 semble être l'H.264 sans les inconvegnants, pourquoi certaines entreprises/organisations s'entête à suporter des codecs tel que l'ogg theora, et le WebM ? ok sur le papier WebM = H.264 libre et un poid divisé par deux pour la même qualité, dans cet article on nous fait comprendre qu'en fait le WebM ne serait pas totalement aboutit.. La solution serait que tout le monde se tourne vers le x264, ou alors j'ai rien compris !?
avatar nona | 
Ziflame a écrit: ~ ~ Les brevets logiciels n'ont aucune valeur chez nous. ~ German High Court Declares All Software Patentable : http://tinyurl.com/38p7xwt [slashdot.org]
avatar gl3am | 
Il y a fort a parier que VP8 et H.264 coexisteront pour la balise 'video' de HTML5, comme on a gif, jpeg, png pour la balise 'img'
avatar Ziflame | 
[quote=gl3am] C'est une petite bombe que viennent de lancer Google, Mozilla et Opéra ! Que va faire Apple ?[/quote]J'aime beaucoup la progression : Google, Mozilla et Opéra. Vous vous rendez compte que c'est aussi pertinent que de parler respectivement de Wal-Mart, l'épicier bio du coin et le mec qui vend des fraises de son jardin au bord de la route ?
avatar hok | 
Regardez l'ensemble des brevets de AVC (H.264) sur le site du mpeg-la, il y a pleins de brevets francais (de france télécom par ex), alors le mythe de la france saine et sauve...
avatar Ziflame | 
@nona: pitié, par encore ce lien. Apprends un peu de droit et tu t'apercevras que si dans les pays de droit anglo-saxon, la jurisprudence fait les lois, ce n'est pas le cas pas chez nous. Un tribunal allemand qui déclare ce genre de chose n'a aucune valeur contraignante, pour personne. C'est probablement simplement un juge mal informé qui a mal jugé une affaire. Et l'Europe est assez claire sur la question des brevets logiciels. C'est niet.
avatar nona | 
Résumons la situation. Je crois qu'on peut la formuler en une seule phrase : "C'est pas fait par Apple donc c'est nul". Voilà, tout est dit! Inutile de tergiverser beaucoup plus... Bonne fin d'après-midi les gens gentils, Ayumi
avatar Hindifarai | 
On sent tellement d'amertume dans cet article et les premiers commentaires que ça fait sourire. Pour ceux qui doutent du futur format qui s'imposera, regardez du côté des partenaires de webM, les quelques défauts soulevés vont disparaitre rapidement. Les premiers logiciels pros (studios télés...) sont déja en dev, oui c'est rapide. Quant aux specs, les personnes à qui c'est adressé seront certainement moins perdues que l'article ne laisse le penser, non en fait j'en suis même certain :) .
avatar Psylo | 
Très bonne nouvelle pour le web ! Une solide alternative aux couteuses licences H264. Concernant la qualité d'encodage et les perfs de décodage, il faudra attendre un peu d'optimisation (et sans doutes des avancées coté hardware), à priori H264 semble s'en sortir légèrement mieux (mais les chiffres des benchmarks sont comme les humains, quand on sait les torturer on leur fait dire ce qu'on veux entendre) PS @Macgé : Copier-coller-réarranger-tronquer et sortir un peu de leur contexte des commentaires d'un autre site pour écrire un article sur macgé, c'est limite.
avatar USB09 | 
Bouhou hou ! Leave Apple alone !
avatar hawker | 
@amnesique le probleme du x264 c'est qu'il viole plin de brevet lié au h264 puisque qu'il est basé dessus. Ça commence a souler, ces abrutis veulent imposer le h264 mais ils en empêche l'implémentation a cause des brevet en même temps, jt'oblige a le prendre mais j'veux pas le donner. pff Vive le webm mais je suis deg si ce qui est écrit est vrai, j'aimerais qu'il soit impeccablement finalisé. Enfin bref j'espère que c'en sera fini du propriétaire obsolète bientôt.
avatar Wolf | 
Donc si j'ai bien compris, y'a de fortes chances que WebM viole allegrement quelques brevets. Donc c'est mort né. (encore une fois si j'ai bien compris)
avatar lukasmars | 
Marrant comme on sous entend que les projets libre violeraient des brevets trés souvent mais les logiciels proprietaires n'en violeraient jamais ...
avatar bugman | 
"De telle manière qu'un programmeur pourrait théoriquement être à même de "lire manuellement" le contenu d'un fichier rien qu'en regardant les données binaires. " Ca commence fort dis donc ! Matrix ? Bon, je m'en vais de ce pas lire la suite... "il est donc impossible de les corriger et/ou de les améliorer. Google a d'ores et déjà refusé les amendements qui lui ont été soumis, et à moins de lancer un nouveau profil pour le VP8, il faudra donc faire avec les bugs que le codec recèle…" J'ai jamais vu un codeur (ou une société) voir les choses comme ça, c'est idiot. google est con comme une paillasse ? " L'iPhone, l'iPod touch et l'iPad ne gèrent que le profil "baseline" du standard et non ses implémentations plus performantes. Moralité c'est un nivellement par le bas pour qui tient à proposer des vidéos compatibles avec ces appareils. Le Blu-ray connait également la même problématique avec certains lecteurs de première génération." (troll (je me fais plaisir pour le coup)) : Ils n'ont qu'a se sortir les doigts du cul (ces grosses feniasses) ! :D Pour le reste, et bien, comme d'hab (pour les users/devs), on suivra les recommandations et on s'adaptera a la techno qui est retenue.
avatar Orus | 
Bravo Google ! C'est maintenant lui qui innove sans arrêt et surtout qui nous fournit du contenu gratuit et ouvert. Apple n'est plus qu'un Microsoft de plus. Et d'ailleurs le jour ou Google concevra et vendra ses propres ordinateurs, cela sera un cataclysme pour Apple.
avatar brume | 
amnesique, hawker x264 est le nom d'un encodeur h264, pas un autre format...
avatar davitron | 
Ce qui serait bien senti de la part de MPEG-LA c'est de modifier leur licence pour en réduire le prix et rassurer sur la durée. Ca tuerait VP8 dans l'oeuf qui aurait eu comme principal mérite d'avoir fait bouger MPEG-LA. Parce que si VP8 est à peu près identique techniquement à H264, alors ce serait quand même plus malin de faire évoluer la licence de H264 d'une façon qui satisfasse tout le monde, plutôt que de devoir modifier tous les hardwares pour passer à VP8. Ce qui me surprend, c'est que Google ait sorti son VP8 (racheté de On2) sans évoquer à un seul moment d'éventuels conflits de brevet... Il joue les naïfs ou il y a un truc béton duquel tout le monde est passé à côté ?
avatar gl3am | 
@orus Il ne faut pas croire que Google innove pour le bien du web ! Il innove pour son propre bien, pour son business ! Il est comme tous les autres, ni pire (quoi que ?) ni meilleur !
avatar voz | 
@davitron Il y a une close dans la licence de VP8 qui vous interdit l'exploitation gratuite du codec si vous vous lancez dans un procès contre lui. En gros c'est son utilisation massive par l'industrie qui le protège...
avatar gto55 | 
H265 déjà en préparation :) http://en.wikipedia.org/wiki/High_Efficiency_Video_Coding

Pages

CONNEXION UTILISATEUR