L’année 2012 marque pour Mozilla l’intensification des travaux dans plusieurs directions. On sait désormais que l’éditeur a des ambitions dans le secteur mobile avec le projet Boot To Gecko, ou B2G. Mais pour être capable de proposer une expérience utilisateur digne de ce nom, Mozilla doit entre autres proposer la lecture native de certains codecs multimédias, à commencer par le H.264. C'est désormais chose faite.
En termes d’expérience utilisateur et de concurrence, la question du support de certaines technologies devient pratiquement hors sujet. Il n’est plus imaginable aujourd’hui de commercialiser un smartphone qui ne saurait lire ni le MP3 ni le H.264. Mais en ce qui concerne ce dernier, la situation est d’autant plus concrète que ce codec vidéo est très utilisé, notamment sur la toile.
Mozilla avait expliqué vouloir supporter le H.264, sans pour autant s’occuper lui-même du décodage. Dans la pratique, l’idée était d’exploiter les capacités sous-jacentes du système d’exploitation. Dans Boot To Gecko, les développeurs ont utilisé la bibliothèque « stagefright » issue d’Android pour la placer dans la base Linux. Conséquence : le système est capable de décoder le H.264, l’AAC et le MP3, tous les trois massivement utilisés aujourd’hui par tout un chacun.
L’avantage pour Mozilla est que Boot To Gecko peut lire une vidéo H.264 par exemple depuis un dossier, ou directement dans le navigateur si un site présente un tel contenu. Le navigateur lui-même ne décode pas le H.264, il interprète simplement ce qui est renvoyé par le système d’exploitation.
Selon Mozilla, l’implémentation du H.264 est encore un travail en cours, et de nombreux bugs sont encore présents. B2G n’est pas attendu avant la fin de l’année, voire au début de l’année prochaine. Mais si le système mobile représente une étape marquante, elle n’est que la première. Car la boite de Pandore a été ouverte. Certains crieront à la trahison pour avoir laissé passer une technologie protégée par des centaines de brevets. D’autres y verront une nécessaire adaptation prête à rejaillir sur les autres créations de l’éditeur, car tout ne semble plus qu’une question de temps.
Ainsi, Chris Double, développeur chez Mozilla, explique sur son blog que le travail est bien en cours pour Firefox sur Android. La même technique peut être reprise : la bibliothèque stagefright est bien sûr présente dans Android. Toutefois, la situation est rendue plus complexe par la disponibilité de versions multiples, en fonction de l’édition d’Android. Mozilla pourrait utiliser plusieurs plug-ins pour parer à toutes les éventualités, ou déterminer de manière dynamique quelles sont les fonctions à utiliser selon la version d’Android présente.
La situation sur les ordinateurs classiques, fixes ou portables, est plus délicate encore. En effet, en dehors de systèmes récents tels que Windows 7, la plupart ne possèdent pas la capacité de lire nativement le contenu H.264. L’une des solutions envisagées serait de passer par le framework multimédia GStreamer, mais rien n’est encore arrêté.
Mozilla ne semble pas vouloir se lancer dans la solution qui pourrait apparaître comme la plus simple : ouvrir les vannes aux capacités du système d’exploitation. L’éditeur souhaite pouvoir dire « Notre navigateur supporte H.264 » sans que l’utilisateur ait à se demander si son système le permet.
En termes d’expérience utilisateur et de concurrence, la question du support de certaines technologies devient pratiquement hors sujet. Il n’est plus imaginable aujourd’hui de commercialiser un smartphone qui ne saurait lire ni le MP3 ni le H.264. Mais en ce qui concerne ce dernier, la situation est d’autant plus concrète que ce codec vidéo est très utilisé, notamment sur la toile.
Mozilla avait expliqué vouloir supporter le H.264, sans pour autant s’occuper lui-même du décodage. Dans la pratique, l’idée était d’exploiter les capacités sous-jacentes du système d’exploitation. Dans Boot To Gecko, les développeurs ont utilisé la bibliothèque « stagefright » issue d’Android pour la placer dans la base Linux. Conséquence : le système est capable de décoder le H.264, l’AAC et le MP3, tous les trois massivement utilisés aujourd’hui par tout un chacun.
L’avantage pour Mozilla est que Boot To Gecko peut lire une vidéo H.264 par exemple depuis un dossier, ou directement dans le navigateur si un site présente un tel contenu. Le navigateur lui-même ne décode pas le H.264, il interprète simplement ce qui est renvoyé par le système d’exploitation.
Selon Mozilla, l’implémentation du H.264 est encore un travail en cours, et de nombreux bugs sont encore présents. B2G n’est pas attendu avant la fin de l’année, voire au début de l’année prochaine. Mais si le système mobile représente une étape marquante, elle n’est que la première. Car la boite de Pandore a été ouverte. Certains crieront à la trahison pour avoir laissé passer une technologie protégée par des centaines de brevets. D’autres y verront une nécessaire adaptation prête à rejaillir sur les autres créations de l’éditeur, car tout ne semble plus qu’une question de temps.
Ainsi, Chris Double, développeur chez Mozilla, explique sur son blog que le travail est bien en cours pour Firefox sur Android. La même technique peut être reprise : la bibliothèque stagefright est bien sûr présente dans Android. Toutefois, la situation est rendue plus complexe par la disponibilité de versions multiples, en fonction de l’édition d’Android. Mozilla pourrait utiliser plusieurs plug-ins pour parer à toutes les éventualités, ou déterminer de manière dynamique quelles sont les fonctions à utiliser selon la version d’Android présente.
La situation sur les ordinateurs classiques, fixes ou portables, est plus délicate encore. En effet, en dehors de systèmes récents tels que Windows 7, la plupart ne possèdent pas la capacité de lire nativement le contenu H.264. L’une des solutions envisagées serait de passer par le framework multimédia GStreamer, mais rien n’est encore arrêté.
Mozilla ne semble pas vouloir se lancer dans la solution qui pourrait apparaître comme la plus simple : ouvrir les vannes aux capacités du système d’exploitation. L’éditeur souhaite pouvoir dire « Notre navigateur supporte H.264 » sans que l’utilisateur ait à se demander si son système le permet.
Source :
Chris Double
Vincent Hermann
Rédacteur/journaliste spécialisé dans le logiciel et en particulier les systèmes d'exploitation. Ne se déplace jamais sans son épée.
Le 4 juin 2012 à 16:08
(10 108
lectures)
Il y a 35 commentaires
Bah, démerdes toi
Plus sérieusement, tu peux essayer "Flash Video Replacer".
Et pour VLC, je peux pas dire, ça fait des plombes que je ne l'utilises plus
Plus sérieusement, tu peux essayer "Flash Video Replacer". Et pour VLC, je peux pas dire, ça fait des plombes que je ne l'utilises plus
OMG! J'ai profité de l'occasion pour refaire quelques tentatives et en insistant lourdement j'ai enfin réussi a faire marcher VLC sur YouTube !!
En fait si on copie directement l'URL de la vidéo (j'utilise Flash Video Downloader pour extraire le lien direct facilement) dans la barre d'adresse, le plugin VLC s'affiche et lance la vidéo sans problème. Mais si on l'insère dans la page (une balise "object" avec le lien dans l'attribut "data", comme génère ViewTube), le plugin s'affiche correctement mais ne charge pas la vidéo.
Le plus étrange c'est que j'ai écrit une page HTML de test avec exactement la même balise pointant vers un fichier vidéo local, et tout fonctionne très bien. Mais si je remplace cette URL par une vidéo YouTube, la vidéo n'est plus chargée...
Je présume que le problème vient donc des URL complètement débiles à rallonge de YouTube et qu'en passant par la barre d'adresse le lien est traité différemment et donc ça passe... @jb : JB !!! Y a un bug dans VLC !
Bref, maintenant j'ai enfin une roue de secours pour les vidéos normales, c'est parfait.

Edité par Oungawak le lundi 4 juin 2012 à 23:56
Nan mais là c'est peine perdue: essayer de convaincre ceux qui publient une source montée sur plusieurs plateformes de choisir un format par plateforme, alors qu'un seul - à fortiori le meilleur de loin - est faisable me paraît compromis, pour parler simplement. 

En terme de performance, c'est kifkif. Les seuls démarques notables sont sur les scènes rapides, en faveur de H.264, et les scènes fixes, en faveur de WebM.
La seul démarcation indiscutable de H.264, c'est sa prise en charge matérielle.
J'ai déjà trop blablaté là-dessus. Il n'y a rien-du-tout en faveur de WebM... rien... en terme de tout...
Ce que l'on peut concéder, c'est son appartenance à Google pour ceux qui considèrent que c'est un +, et une "liberté" supposée et toute relative, qui est son unique atout ... Sinon, pas de dering, deblock, cabac, implémentation 0, spec gruyère, pas accéléré.
Je concède que VP8 a évolué depuis le VP3/Theora qu'on a aussi essayé de nous gonfler à l'époque, c.a.d. qui si tu voulais le retrouver là, chapitre "objective quality", il serait 3ème sur 8 (ce qui je le concède à nouveau est une belle prestation), assez loin derrière high et main... de H264.
Quant à ma réponse quotée, je rappelle qu'elle concernait la circonstance précise de l'éventuelle tentative de convaincre un pro de dupliquer ses profils de diffusion, et qu'il fallait être très persuasif pour qu'il ajoute à ce qu'il aura fait pour HDTV, VOD, BD et iMachins.
Sinon, pas de dering, deblock, cabac, implémentation 0, spec gruyère, pas accéléré.
Platoona, sort de ce corps
Je concède que VP8 a évolué depuis le VP3/Theora qu'on a aussi essayé de nous gonfler à l'époque, c.a.d. qui si tu voulais le retrouver là, chapitre "objective quality", il serait 3ème sur 8 (ce qui je le concède à nouveau est une belle prestation), assez loin derrière high et main... de H264.
Ué, enfin, là, tu compare de l'ASP avec de l'AVC, normale que l'ASP se fasse enterré. Autant reprocher au PIV de se faire assassiner par l'i7
Quant à ma réponse quotée, je rappelle qu'elle concernait la circonstance précise de l'éventuelle tentative de convaincre un pro de dupliquer ses profils de diffusion, et qu'il fallait être très persuasif pour qu'il ajoute à ce qu'il aura fait pour HDTV, VOD, BD et iMachins.
Effectivement, si tu commence tes efforts de persuasion de cette manière, ça risque pas d'aller bien loin
Fait ce que tu veux, mais vient pas te plaindre si le MPEG-LA s'autorise à venir frapper à la porte de tes clients afin de réclamer quelques deniers supplémentaire ou payer de nouveaux droits d'utilisations ^^
Effectivement, si tu commence tes efforts de persuasion de cette manière, ça risque pas d'aller bien loin
À vrai dire moi je ne suis pas à persuader, et je n'ai personne à persuader, puisque les pro dont nous parlons sont déjà du même avis que moi (puisqu'à l'usage, ils sont arrivés à la même conclusion que moi). Donc effectivement, ça va pas aller bien loin : les "HDTV, VOD, BD et iMachins" sont tous dans le format incluant H264, et il se trouve que sur le web, ce même format est totalement géré aussi par 2 des 3 OS principaux (donc API système jouable si browser incapable par défaut)... ainsi que par Mozilla maintenant un petit peu aussi - c'est le sujet de la news -, en attendant une souhaitable extrapolation à la version desktop (j'utilise Fx et en suis satisfait, ça me ferait plaisir).
Au pire, on peut toujours se dire que "ça va un peu plus loin" que la manière désinvolte dont tu traites les pistes que je te donne, ou à la vacuité des arguments que tu y opposes.
Fait ce que tu veux, mais vient pas te plaindre si le MPEG-LA s'autorise à venir frapper à la porte de tes clients afin de réclamer quelques deniers supplémentaire ou payer de nouveaux droits d'utilisations ^^
Il n'est plus possible de commenter cette actualité
Vous devez être connecté ou vous inscrire en haut pour pouvoir participer aux commentaires.
















