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