L'élement video
Par Laurentj le jeudi, octobre 16 2008, 11:13 - Technologies Web - Lien permanent
Il y a plus d'un an, j'avais publié un billet sur l'élément <video>. Les choses ont un peu évolué, les implémentations et les interrogations aussi. Voici donc un récapitulatif des avantages de cet élément sur l'élément <object>, ainsi que quelques démonstrations. On peut espérer que la balise object ne sera plus trop utilisée pour insérer de la vidéo : l'élément <video> est déjà présent dans Safari 3.1, dans des versions expérimentales d'Opéra, et la version beta1 de Firefox 3.1 qui vient de sortir.
Les avantages sur l'élément object et le flash
Écriture de l'élément
L'élément <video> est plus simple à écrire, car il y a moins de paramètres que l'élément <object>, et sont en tout cas plus intuitifs.
L'élément video propose aussi des attributs permettant de spécifier des choses qu'on ne peut faire avec une balise object :
- l'attribut
poster, qui offre la possibilité de spécifier une image, qui sera affichée en attendant que la vidéo soit téléchargée et puisse démarrer - des attributs
startetendpermettant de spécifier quel est le morceau de la vidéo à jouer - des attributs
loopstart,loopendetplaycountpermettant de jouer en boucle la vidéo (ou une partie), un certain nombre de fois ou indéfiniment.
Note: l'utilisation de ces derniers attributs dépendront des possibilités du format video, mais à priori, ce sera possible par la plupart.
Simplicité de l'API
Au niveau de l'API : alors que chaque plugin propose au travers de l'élément <object>, une API différente (voire pas du tout quand c'est une video embarquée dans du flash), l'élément <video> propose une API unifiée. On a ainsi toujours les mêmes méthodes, play(), pause() etc, quelque soit le format de la vidéo et du navigateur.
Autre chose : le navigateur peut offrir la possibilité de faire du plein écran, mais c'est uniquement l'utilisateur qui peut l'activer (au navigateur de proposer un bouton quelque part), il n'y a pas d'API pour ça, car cela peut causer des problèmes au niveau sécurité (montrer une fausse interface dans la vidéo etc..)
Meilleure ergonomie
Il est possible d'indiquer dans l'élément <video>, l'interface que l'on veut utiliser : soit on veut que le navigateur affiche des boutons par défaut (lecture, arrêt etc..), soit on affiche soit même ses propres boutons (en html). Cela permet alors une meilleure intégration dans le navigateur et interactivité avec le navigateur dans le premier cas (en facilitant le travail du développeur), ou une meilleure intégration dans la page HTML pour le deuxième cas. Fini les lecteurs flash qui jurent avec le design du site, et que l'on ne peut modifier.
Et bien sûr, on peut imaginer que l'utilisateur puisse configurer son navigateur de façon à toujours afficher les boutons par défaut, de telle manière que l'interface de pilotage de lecture de la vidéo soit toujours la même.
Meilleure Accessibilité
Bien entendu, l'élément video a une valeur sémantique, qui permet à tout navigateur de savoir implicitement qu'à l'endroit où il y a l'élément <video>, il y a une vidéo. Un navigateur prenant en compte un handicap spécifique, peut alors mieux agir sur le contenu. Et comme il y a une API unifiée, il peut piloter la lecture de la vidéo : il peut en effet proposer une interface spécifique pour l'utilisateur, pour lire le contenu. Par exemple, afficher des gros boutons pour les mal-voyants, lancer la vidéo dans une autre fenêtre en zoomant dessus etc..
Format des vidéos
Les premiers "brouillons" de la spécification de l'élément <video> dans HTML5 préconisaient l'implémentation par défaut du format Ogg Theora, un format vidéo ouvert et libre. Cependant, certains ont estimé qu'il viole potentiellement des brevets logiciels, et comme il est trop compliqué de vérifier si c'est vraiment le cas, la préconisation a été enlevée. Libre à l'implémentation de supporter les formats qu'il veut. Mais la spécification recommande tout de même de supporter le maximum de format.
Ce n'est cependant pas un problème. Mozilla a choisi de supporter en natif le format Ogg Theora dans Firefox 3.1. Cela encouragera à l'utilisation de ce format libre et ouvert. Un lecteur Ogg Theora installé chez 30% des internautes, ça sera cool non ? Pour les autres formats, Firefox s'appuiera sur l'interface système du système d'exploitation, dédiée au medias. Ainsi Firefox fera appel à DirectShow sur Windows, Quicktime sur MacOs, GStreamer sur Linux etc, pour afficher les vidéos à l'intérieur de la page web.
Pour offrir de meilleur chance de permettre de lire une vidéo, il est possible de proposer plusieurs fichiers dans des formats différents. Ainsi le navigateur pourra choisir le format le mieux adapté ou celui qu'il est capable de lire. Par exemple, on peut proposer la vidéo au format Ogg Theora, mais aussi au format Quicktime. Cela se fait grâce à l'élément <source> :
<video autoplay controls>
<source src="foo.ogg" type="video/ogg"></source>
<source src="foo.mov"></source>
Votre navigateur ne reconnait pas la balise <code>video</code>
</video>
C'est encore une chose qu'il est plus compliqué de faire avec une balise <object>
L'élément <audio>
À noter que dans les spécifications de HTML5, il y a aussi une balise <audio> pour laquelle on retrouve les mêmes avantages que l'élément <video> par rapport à l'élément <object>.
Et pour les vieux navigateurs ?
Il est possible de mettre du HTML à l'intérieur de l'élément <video>. Ce code HTML sera naturellement affiché par les navigateurs ne connaissant pas cet élément (puisqu'il l'ignorera alors..). Par contre, ce code HTML ne doit pas être interprété par les navigateurs supportant l'élément <video>. Aussi, pour les vieux navigateurs, vous pouvez mettre par exemple un simple message indiquant d'aller télécharger la dernière version de Firefox/Safari/Opera, ou alors vous pouvez mettre un élément object qui afficherait alors la vidéo par l'intermédiaire d'un plugin. Pour les utilisateurs d'anciens navigateurs, ils ne profiteront pas de tout les avantages cités précédemment (interface native, accessibilité etc..), mais au moins ils pourront profiter de la vidéo par le biais d'anciens moyens. Une transition en douceur... Un exemple
<video src="mavideo.ogg">
<p class="avertissement">Pour profiter au maximum de la vidéo et des possibilités de cette page web, vous devriez installer un navigateur récent : Firefox 3.1, Safari, ou Opera.</p>
<object>
<param name="movie" value="flvplayer.swf?file=mavideo.flv"></param>
<embed src="flvplayer.swf?file=mavideo.flv" type="application/x-shockwave-flash"></embed>
</object>
</video>
Exemples dans Firefox 3.1 beta 1
Comme je disais, l'un des intérêts de l'élément <video>, c'est que le navigateur peut fournir les boutons de base pour manipuler la vidéo, si vous le souhaitez. Il suffit d'indiquer l'attribut controls :
<video id='v1' src="ascannerdarkly480.ogg" controls="controls"></video>
Dans Firefox 3.1beta1, quand vous survolez la vidéo avec la souris, une barre de boutons apparait en bas, ici quand la vidéo est en pause :

Et quand elle est en lecture :

Pour l'instant, cette interface est assez minimaliste mais elle va s'enrichir d'ici la version finale de Firefox 3.1.
Si on ne veut pas de ces contrôles par défaut, on ne met pas cet attribut controls, et on ajoute des boutons HTML qui appelleront les fonctions javascript de la balise <video> :
<button onclick="document.getElementById('v1').play()">Play</button>
<button onclick="document.getElementById('v1').pause()">Pause</button>
<button onclick="document.getElementById('v1').volume += 0.25">Volume Up</button>
<button onclick="document.getElementById('v1').volume -= 0.25">Volume Down</button>
<button onclick="document.getElementById('v1').muted = true;">Mute</button>
<button onclick="document.getElementById('v1').muted = false">Unmute</button>
<div>
<video id="v1" src="smeck.ogg" />
</div>
Notez les méthodes et propriétés play(), pause(), volume etc.. Voici ce que ça donne :

Ici les boutons ne sont pas très joli, mais il y a une autre démo sur le site d'Opéra qui montre des boutons dans une div superposée qui apparaît en "glissant" au passage de la souris, comme dans Firefox 3.1 ou dans certains lecteurs flash, habillée avec de la transparence en CSS. Cela montre que l'on peut donc tout à fait jouer avec la balise <video> comme n'importe quel autre balise HTML :

Vous avez aussi à votre disposition une liste d'événements DOM qui vous permettent d'être tenu informé de certaines choses (qu'il y ait controls="controls" ou pas) lors de la lecture de la video, ainsi vous pouvez réagir dans votre page web. Vous pouvez donc programmez des choses lors de la progression de la lecture, lorsque le téléchargement débute ou fini, sur le changement du volume etc.. En voici une liste : "begin", "progress" "loadedmetadata" "emptied" "stalled", "play", "pause" "waiting" "timeupdated" "ended" "dataunavailable" "canplay" "canplaythrough" "ratechange" "durationchange" "volumechange" "canshowcurrentframe" "loadedfirstframe".
Voici une autre démonstration, qui montre deux videos intégrées dans du SVG, avec "des poignées" pour les tourner et les agrandir, comme dans une des démos que j'avais signalé en février, sauf qu'au lieu d'images fixes, ce sont des vidéos :

Bref, tout ces exemples montrent bien la supériorité de la balise <video> sur l'utilisation d'un plugin flash ou de la balise object : on peut mieux contrôler son affichage et son fonctionnement, donc mieux l'intégrer dans des pages web. Et en beaucoup moins lourd.
Pour tester ces exemples, téléchargez Firefox 3.1 beta1 et allez sur cette page.
Mise à jour 31/10/2008 : rajout des explications sur l'élément <source>.
Commentaires
En voilà une bonne nouvelle, une raison de plus pour laisser tomber les anciens navigateurs. Il me tarde de pouvoir essayer tout ça.
C'est cool, car comme dans le flux, « <video> » n'est pas transcrit en « <video> », il n'apparaît pas dans l'agrégateur et ainsi l'incohérence du titre et de l'introduction incitent à lire de quoi il s'agit.
Je sais pas pourquoi, mais je sens que ça va faire de la concurrence au format FLV et aux players flash.
Les lecteurs vidéos jusqu'à présents étaient tous un peu différents, avec cette balise on risque de voir apparaitre une certaine homogénéité des interface ... bon, ou pas ?
Je trouve que ce tag va rendre plein de services aux développeurs mais pas aux utilisateurs et je pense que son adoption par les sites sera très lentes car il n'est pas iso-fonctionnel avec ce que propose flash actuellement ... et c'est bien dommage ...
Les sites de vidéo ne voudront pas revenir en arrière sur ce que permet flash aujourd'hui, or cet élément video ne propose pas :
- la lecture plein écran (rien que ça, c'est une catastrophe pour son adoption, bien plus que le non support des anciens navigateurs).
- le fait de pouvoir accéder directement à une partie de vidéo qui n'est pas encore chargée.
Bref, je ne vois pas les les sites comme youtube, dailymotion & co passer à cette méthode d'intégration de leurs vidéos tant qu'il n'y aura pas ces fonctions de base. Sans parler du fait qu'il est impossible de "masquer" la source de la vidéo ce qui ne va pas plaire à tout ceux qui ne souhaitent pas les téléchargement direct de leurs flux...
Quelques précisions pour faire mon pinailleur.
La balise vidéo n'est pas supportée dans tous les navigateurs basés sur WebKit. Il faut qu'un backend existe. Pour l'instant, le seul implémenté est Quicktime (sauf si je dis des bêtises).
L'implémentation dans Safari 3.1 n'est pas complète. Il manque par exemple la gestion de l'attribut controls (cf http://webkit.org/blog/140/html5-me... ). C'est beaucoup plus complet dans les nightlies actuelles de WebKit.
Opera n'implémente pas encore la balise video. Ils ont juste quelques versions expérimentales avec le support. Ils parlent de l'ajouter dans Opera 10.
Sur la balise video, il y a deux points intéressants que tu as oublié de mentionner. L'attribut poster qui permet d'afficher une image avant que la vidéo ne soit téléchargée. Et l'élément source qu'on peut mettre dans la balise video afin de préciser plusieurs sources. Ça peut permettre de faire du fallback si le navigateur ne supporte pas la première source. L'élément source a d'ailleurs un attribut type qui permet de spécifier le codec utilisé par la vidéo.
Enfin côté accessibilité, il y a encore du travail pour la balise video. L'affichage de sous-titres en natif par exemple, la possibilité de lier une partie précise d'une vidéo (imaginons un sujet dans un journal).
Mais ça reste un bon début :)
Merci Rik pour ces précisions sur webkit et opéra. Ce n'est pas toujours facile de suivre l'actualité détaillée de tout les moteurs de rendu :-)
Pour le reste des spécifications de la balise video, j'ai oublié d'en parler. Je vais compléter mon billet :-)
@SToto98 : tu devrais lire plus attentivement les spécifications :-)
Quand la balise video sera totalement implémenté dans les navigateurs (pour l'instant, tout les attributs ne sont pas supportés dans Firefox par exemple), je vois pas ce qu'il manquera pour être isofonctionnel avec les trucs en flash (je dirais même que la balise video sera bien mieux, vu les possibilités d'accessibilité et cie)
La spécification précise bien que le navigateur peut proposer le plein écran, mais seulement dans son interface à lui : il n'y a pas d'API en JS pour que la page l'active d'elle-même, pour des raisons de sécurité.
Ensuite, l'accés à une partie de la vidéo, bien sûr que ce sera possible, il y a toute l'API DOM et attributs pour le faire, mais ça, ça dépend plus du format qu'autre chose.
(J'ai mis à jour mon billet pour indiquer ces deux points).
Concernant l'adoption, apparement, tu as mal lu le paragraphe sur les "vieux" navigateurs : un développeur web peut tout à fait proposer la balise video ainsi que la vieille balise object pour rester "compatible" sur tout les navigateurs. Et ils auront tout interêt à utiliser cette balise vidéo, pour les internautes qui ont un navigateur supportant la video, mais n'ayant pas les plugins flash ou autre (donc balise object inopérante).
L'url d'un flux peux toujours être récupérée, c'est du pinaillage ce genre de truc. J'ai vu des programmes très simple d'utilisation pour "sniffer" les requêtes web et permettant de récupérer les urls et ce genre de contenu.
Ca part d'un bon sentiment, mais il ni a aucune chance pour que cette nouvelle balise remplace le flash. A l'heure de la vidéo HD en streaming, la technologie flv a pris trop d'avance et elle est propulsée par une seule société, là où la balise vidéo sera soumis à l'interprétation de quatre navigateurs concurrent.
Si j'ai besoin de présenter une vidéo je choisis la technologie présent dans plus de 90 % des navigateurs.
Et même dans 5 ans ( je suis optimiste ) quand cette balise sera elle aussi présente dans 90 % des navigateurs, flash proposera de nouvelles fonctionnalités qui seront surement devenues indispensable.
C'est une excellente idée cette balise ( comme l'opacité, les ombres portées, les coins arrondis :) ), mais va falloir la revoir à la hausse pour remplacer sont concurrent direct.
@lipki
> A l'heure de la vidéo HD en streaming
Il n'y a pas de codec dans Windows, Linux et Mac pour des formats en HD ??
"Ainsi Firefox fera appel à DirectShow sur Windows, Quicktime sur MacOs, GStreamer sur Linux etc."
Ça me fait très peur ça. On va vers une multitude de formats vidéo différents, qui fonctionneront une fois sur 40...
@Laurentj : merci pour les précisions sur le plein écran, effectivement je ne me suis pas lu la spec intégrale, je comptais sur toi pour nous en faire un résumé (oui je suis un développeur flemmard).
Pour l'accès à une partie de la vidéo, je reporte donc la question sur le support de cette fonction par les codecs qui seront adoptés (ogg theora au moins donc).
Pour les vieux navigateurs, j'avais bien compris l'astuce ;-)
Par contre pour le pinaillage sur la récup des fluxs, là je sais bien que rien n'est impossible et que les outils pour trouver les sources des flux des vidéos flash existent à la pelle. Ceci dit, entre utiliser un outil de ce type et se contenter d'éditer le source HTML d'une page, il y a quand même une marge de compétences et de motivation à franchir. M'enfin en l'occurrence moi j'aime le web ouvert et je me fais ici l'avocat du diable parce que je sais bien qu'il s'agit des questions que vont se poser les petits [ayant droits|marketeux] désireux de continuer à se remplir les poches à coup de pub et de droits d'auteurs...
« Il y a plus d'un an, j'avais publié un billet sur l'élément <video>. »
Voir aussi http://ljouanneau.com/blog/post/200... .
« Les avantages sur l'élément object [...] L'élément <video> est plus simple à écrire, car il y a moins de paramètres que l'élément <object>, et sont en tout cas plus intuitifs. »
élément object minimal : <object data="video.mp4" type="video/mp4" />
élément video minimal : <video src="video.mp4" type="video/mp4" />
élément video avec compatibilité html 4 (cf. partie « Et pour les vieux navigateurs ? ») : <video src="video.mp4" type="video/mp4" ><object data="video.mp4" type="video/mp4" /></video>
« L'élément video propose aussi des attributs permettant de spécifier des choses qu'on ne peut faire avec une balise object »
Rien n'empèche les auteurs de la spécification html 5 d'ajouter aussi ces attributs à l'élément object dans la spécification html 5.
« Simplicité de l'API »
Rien n'empèche les auteurs de la spécification html 5 d'ajouter aussi cette api à l'élément object dans la spécification html 5.
« l'élément video a une valeur sémantique, qui permet à tout navigateur de savoir implicitement qu'à l'endroit où il y a l'élément <video>, il y a une vidéo. »
Rien n'empèche le logiciel de voir « type="video » et d'en déduire qu'il s'agit d'une vidéo.
« Et comme il y a une API unifiée »
Cf. plus haut.
>élément object minimal
des plugins (comme flash) nécessitent souvent des balises param supplémentaires
>Rien n'empêche les auteurs de la spécification html 5 d'ajouter aussi ces attributs à l'élément object dans la spécification html 5.
Mais oui bien sûr, ça a vachement de sens d'avoir un attribut start, loopstart, poster et cie, sur une balise object utilisée pour inclure un objet svg, un objet flash, un objet pdf ou que sais-je encore.
Si ils ne l'ont pas fait, c'est pour des raisons de cohérences. Sinon alors, autant n'avoir en html qu'une seule balise object, et mettre type="p", type="h1"... Ce serait pratique tient...
Ah, et aussi, il n'y a pas d'attribut type sur un élément video.
Franchement, si ça fonctionne aussi bien que c'est énoncé ici à moindre effort pour celui qui crée une vidéo, ça sera très intéressant (en créant moi-même, je suis cela d'un oeil très intéressé).
J'attends de voir ça dès que Firefox 3.1 sort !
@LaurentJ : Je pinaille peut-être un peu, mais l'attribut controls n'a pas de valeur, ce n'est pas valide sinon ;-)
Tu pinailles un peu trop : spécification des attributs boolean. C'est d'autant plus vrai en XHTML5. (true n'est pas une bonne valeur cependant, je corrige)
@LaurentJ : Ahh merci, je n'arrivais plus à trouver cette partie de la spec ! (trop du mal ce matin)