Systèmes d’Information, Développement Web et Mozilla

Au vue des âne­ries qui fleu­ris­sent en ce moment sur le Web con­cer­nant la balise HTML <video> je pense qu’il est temps de faire une mise au point.

La norme HTML5 est actuel­le­ment en pré­pa­ra­tion par le WHATWG (qui regroupe entre autre Mozilla, Apple et Opera). Parmi la plé­thore de nou­veau­tés il y a la balise HTML <video>. A l’ins­tar de la balise <img> qui per­met d’inclure les ima­ges, elle per­met d’inclure dans une page Web une vidéo. Il est impor­tant de noter que les spé­ci­fi­ca­tions de cette balise ne sont pas figées, HTML5 est d’ailleurs encore en chan­tier et sa der­nière révi­sion (au moment de la rédac­tion de cet arti­cle) date du 6 août 2008.

Quel­les sont les dif­fé­ren­ces avec les bali­ses <embed> et <object> ?

Pour lire une vidéo incluse via les bali­ses <embed> ou <object> il faut que les plu­gins cor­res­pon­dants soient ins­tal­lés sur le navi­ga­teur de l’inter­naute. Quick­time, Win­dows Media Player et VLC par exem­ple, ins­tal­lent leur plu­gins auto­ma­ti­que­ment pour les navi­ga­teurs prin­ci­paux.

L’avan­tage de la balise <video> est de ne plus avoir besoin, en théo­rie, de ces plu­gins. En effet elle uti­lise soit les codecs gérés en natif dans le navi­ga­teur soit les capa­ci­tés de Direct­Show, Quick­time ou Gstrea­mer/Pho­non (res­pec­ti­ve­ment sous Win­dows, Mac et Linux).

La balise <video> apporte aussi une API uni­fiée. On a ainsi tou­jours les mêmes métho­des, start(), stop() etc., quel­que soit le codec de la vidéo. Cette API ouvre la voie à la créa­tion de scripts avan­cés et d’exten­sions Fire­fox pour per­son­na­li­ser la lec­ture des vidéos sur le Web.

Der­nier avan­tage, cette balise apporte de la séman­ti­que, là ou les autres bali­ses étaient vide de sens.

Quel­les sont les dif­fé­ren­ces avec les lec­teurs fait en Flash ?

Pas besoin – en théo­rie – d’avoir à ins­tal­ler un plu­gin par­ti­cu­lier. Même si de nos jours Flash est quasi-omni­pré­sent, il reste encore des cas par­ti­cu­liers (cf. l’iPhone).

Autre pro­blème, c’est le con­cep­teur du lec­teur Flash qui décide de ses fonc­tions. J’ai déjà ren­con­tré des vidéos où l’on ne pou­vait pas avan­cer manuel­le­ment la lec­ture : même si on avait déjà vu la pre­miè­res minu­tes, j’ai été obligé de me les reta­per pour voir la suite. Avec la balise <video> et grâce à son API ou via l’inter­face uti­li­sa­teur du navi­ga­teur (si il le pro­pose), on PEUT choi­sir d’affi­cher ses pro­pres con­trô­les.

Y-a-t-il un sup­port du strea­ming ?

En théo­rie, oui.

Y-a-t-il un sup­port du plein écran ?

La spé­ci­fi­ca­tion de la norme HTML5 recom­mande aux navi­ga­teurs ne pas pro­po­ser cette fonc­tion dans l’API (ce qui nous pro­tège d’un script lan­çant auto­ma­ti­que­ment une vidéo en plein écran). Le plein écran res­tera pos­si­ble à con­di­tion que le navi­ga­teur le per­mette quel­que part dans son inter­face, donc uni­que­ment sur une action de l’uti­li­sa­teur.

Peut-on lire tous les types de vidéos ?

Non, seu­le­ment ceux sup­por­tés par le navi­ga­teur en stan­dard (natif) et ceux dis­po­ni­bles dans le backend du sys­tème d’exploi­ta­tion. Sinon il fau­dra ins­tal­ler un plu­gin et on perd donc un avan­tage de la balise video. Cela nous amène donc au sup­port de Ogg par défaut dans Fire­fox 3.1.

Pour­quoi Fire­fox 3.1 n’implé­men­tera (que) Ogg en natif ?

D’abord un petit rap­pel : Ogg est un con­te­neur, un for­mat de fichier qui con­tient des flux audio et vidéo. Ces flux audio et vidéo peu­vent être codés avec les codecs Theora pour la vidéo et Vor­bis pour le son. Sub­jec­ti­ve­ment, Theora fait par­tie des meilleurs for­mats vidéo du moment, qui sont Theora, xvid, h264 et VC-1. Theora a l’avan­tage d’être libre, ou du moins plus libre que les autres. En plus, on ne lui con­naît pas encore de pro­blè­mes liés aux bre­vets logi­ciels. En con­tre­par­tie c’est pro­ba­ble­ment aussi le moins bon des qua­tre.

On voit donc que n’implé­men­ter aucun for­mat en natif nous ramène au pro­blème d’incom­pa­ti­bi­lité en fonc­tion du sys­tème de l’uti­li­sa­teur (on est dépen­dant du backend) et implé­men­ter un autre for­mat que Ogg peut poser des pro­blè­mes juri­di­ques et finan­ciers à ceux qui les uti­li­sent.

Pour que tout aille mieux dans le meilleur des mon­des il faut donc main­te­nant que les autres navi­ga­teurs sui­vent le mou­ve­ment et un effort de la part des con­cep­teurs de sites Web. Con­cer­nant les navi­ga­teurs, il existe déjà depuis un moment déjà des ver­sions de tests d’Opera sup­por­tant la balise <video> et Ogg en natif. Quant à Web­kit je crains mal­heu­reu­se­ment qu’il n’implé­mente jamais Ogg en natif, Apple pré­fè­rera plu­tôt pous­ser à l’adop­tion de son for­mat féti­che : le h.264. Il faut savoir qu’à l’ori­gine la norme HTML5 obli­geait les navi­ga­teurs a géré Ogg en natif, mais cette obli­ga­tion a été reti­rée suite à des pres­sions d’Apple et de Nokia.

Con­cer­nant les sites Web, Wiki­me­dia Com­mons uti­lise déjà la balise <video> depuis le début et tou­tes les vidéos du site sont au for­mat Ogg, à quand Wiki­pé­dia ?

Pour finir, un exem­ple d’uti­li­sa­tion :

<video controls src="video.ogg" id="myVideo">$</video>

$ = Texte ou code HTML, qui peut être une balise <object> ou <embed> pour pou­voir affi­cher la vidéo dans les navi­ga­teurs ne sup­por­tant pas la balise <video>, mais avec l’incon­vé­nient bien sûr qu’elle n’est plus pilo­ta­ble en javas­cript.

Et si on veut défi­nir ses pro­pres con­trô­les et ne pas uti­li­ser ceux du navi­ga­teur (exem­ple) :

<script>
  var video = docu­ment.getE­le­ment­ById("video"); 
</script> 
<p><but­ton type="but­ton" onclick="video.play();">Lec­ture</but­ton> 
   <but­ton type="but­ton" onclick="video.pause();">Pause</but­ton> 
   <but­ton type="but­ton" onclick="video.stop();">Stop</but­ton><p>

Ce qui nous donne :

Je ferais un lec­teur plus com­plet dès que je trou­ve­rais le temps.