Hello tout le monde,

Depuis plusieurs jours et les annonces coup sur coup des arrêts de flash sur mobile et de silverlight. On peut assister à quantité de troll et de grandes annonces dans tous les sens à propos de la balise vidéo. Voici 2,3 exemples de ce que l’on peut trouver en moins de 2 min dans les commentaires de certains sites d’actu ou sur Twitter (et encore j’ai choisi des exemples soft):

Maintenant, on peut réellement dire que Steve Job a apporté quelque chose de positif à l’informatique

Et ben c’est simple : tes vidéos en streaming vont passer en h264 via html5, idem pour tes vidéos de sites « non-HTML 5 » : ils vont passer au html5

Quand on lit ça sans s’être trop renseigné sur le sujet, on peut effectivement croire que le HTML5 va tout révolutionner et que flash va disparaitre.
Mais voilà, travaillant dans le domaine, lire ce genre de message me fait sourire, si les choses étaient si simples, ça se saurait.

Jusque-là, ça marchait comment le streaming video ?

Le streaming vidéo existe déjà depuis des dizaines d’années et personne n’a attendu le W3C pour s’y mettre heureusement. Suivant le type de streaming vidéo voulu, il existe de nombreux protocoles utilisés :

• RTP/RTSP : Tres utilisé dans l’industrie (box ADSL, transmission satellite, camera IP), car très simple, rapide, basé sur UTP. Il existe depuis un bon moment et est normalisé, ce qui facilite son implémentation. Par contre aucune communication client/serveur, il est vraiment adapté à de la consultation uniquement, c’est-à-dire du live.
• RTMP : Protocole propriétaire d’adobe, basé sur TCP. Très utilisé jusque-là, car sur, sécurisé (possibilité d’utiliser des DRM), facile à mettre en place et surtout possibilité d’utiliser plusieurs flux bidirectionnels en même temps. Donc adapté pour du live, des fichiers static, mais aussi de la visioconférence, du chat. Site connu : Livestream, justin.tv, arte+7 …
• MMS : Protocole propriétaire de Microsoft, qui bénéficie d’une partie des mêmes avantages que celui d’adobe. Par contre gros problème, technologie Microsoft donc serveur Microsoft avec des licences assez chères et aucune alternative à prix modéré. Et surtout l’utilisation obligatoire de windows media player.
• Pseudo-streaming : On arrive enfin au plus utilisé. Ce n’est pas un protocole en soi, c’est simplement la consultation d’un fichier vidéo présent sur un serveur web via http. Gros avantage, aucun problème avec les firewall, accessible via presque n’importe quel device. Par contre, HTTP n’a pas été prévu pour diffuser des médias vidéos, on a donc un flux unique unidirectionnel serveur->client. Donc parfait pour des fichiers static, par contre pas de live ou de visioconférence à l’horizon. Site connu : YouTube, vimeo, dailymotion, …

Hum … trop de techno proprietaire, heureusement le HTML5 va nous sauver …

Le problème est qu’avec toutes ces technologies, il est nécessaire à chaque fois d’avoir le plugin ou le player propriétaire pour accéder aux différents contenus.
Le leader dans le domaine étant sans nul doute flash qui a réussi à s’imposer ces dernières années. Celui-ci est présent sur un grand nombre d’appareils et a fortement contribué à la diffusion du streaming vidéo sur internet. Mais techniquement efficace, car proposant à la fois le RTMP pour tous les professionnels et les applications dédiées, mais aussi le pseudo-streaming pour une diffusion plus simple et moins couteuse.
C’est simple, sans flash on serait encore 10 ans en arrière avec Real Media et Windows media player dispo uniquement sur windows.
Mais voilà, flash n’est pas une fin en soit et il n’est pas parfait, il provoque des plantages, présentes des failles et nécessite que adobe fasse un player pour chaque architecture. Ce dernier point est le plus problématique, car il peut être long d’attendre Adobe, comme ça a été le cas pour les versions 64 bit ou une version Linux stable.
C’est dans ce contexte que le W3C a annoncé vouloir simplifier le streaming vidéo sur internet en proposant une balise HTML unique interprétée par le navigateur. Et il n’en a pas fallu plus pour qu’en pleine guerre des navigateurs, ils annoncent tous coup sur coup le support d’un draft pas encore finalisé.
Enfin la fin d’années de galère ?

… peut-être …

Sur le papier, la balise vidéo du HTML5 parait être une très bonne idée. La voie d’avenir, car présenté comme simple et efficace. Oui mais voilà, pour des raisons de pressions multiples durant la création des spécifications, la norme est réduite au minimum et se trouve quasiment inutilisable en l’état.

Déjà côté diffusion, le HTML5 impose un seul protocole, le pseudo-streaming. Il faut donc que les fichiers soient disponibles sur un serveur web. Pourquoi pas, mais cela exclu déjà une grosse partie des applications puisque pas moyen de faire de live, de chat ou de la visio.

Bon et alors, ça permet quoi de plus qu’avant sinon? Bah c’est là que ça coince, ça n’apporte rien à part la satisfaction de ne plus utiliser flash. C’est juste un player basique géré par le navigateur et personnalisable via js et css. Et c’est là que l’on commence à comprendre que pour le W3C, streaming vidéo = youtube/dailymotion

Et c’est la que le W3C semble avoir fait une première erreur, demander de faire une croix sur la plupart des progrès récents au nom d’une uniformisation bien trop simpliste.

… ou pas!

Et justement là aussi l’uniformisation est assez belle. Les implémentations actuelles ayant toutes été faites sur des drafts non finalisés et assez vagues, la plupart des paramètres n’ont pas le même fonctionnement d’un navigateur à l’autre. Quelques petits exemples :

• muted=’muted’ : Chrome le supporte, mais pas Firefox et iOS qui l’ignore
• autoplay=’autoplay’ : Chrome et Firefox le supporte, mais pas iOS
• controls=’controls’ : pareil

On a seulement une dizaines de paramètres définies sur les balises audio et vidéo, mais une bonne moitié d’entre eux n’ont pas le même fonctionnement suivant le navigateur. Résultat 200 lignes de JavaScript minimum pour compenser les lacunes de la balise de base. Ce à quoi il faut rajouter des défauts encore plus ennuyeux, provenant directement des spécifications comme :

• Aucun contrôle sur les meta
• Pas de fullscreen (laissé à la charge du navigateur)
• Pas de possibilité d’utiliser de DRM
• Aucune communication prévu ce qui oblige à compenser par de l’ajax là ou ça devrait être supporté par le player.

Et alors, j’ai gardé le meilleur pour la fin, le fameux problème de codecs qui après 2 ans de gueguerre n’est toujours pas terminé.

• H264 : IE / Safari / device mobile car accélération matérielle
• Webm : Chrome/Firefox/Opera

et pour la balise audio :

• MP4/MP3 : IE /Chrome/Safari/Opera/device mobile
• Ogg/Theora : Firefox
• Wav : Tous

Cette diversité des codecs est le point le plus problématique, comment faire une solution stable si c’est pour apprendre 3 mois plus tard qu’une navigateur a changé de politique.
Sur un blog avec une utilisation limitée c’est facilement gérable, mais annoncer à un client qu’il va devoir réencoder + de 30 000 vidéos en webm et payer de nouveaux serveurs de stockages et de backup juste pour un ou deux navigateurs web, ça parait déjà bien moins simple.

On arrive donc à l’amer résultat que sur le papier l’idée d’unifier tout en une balise paraissait bonne, mais que le résultat est loin des espérances. Cette balise est contraignante à mettre en place, peu performante, et elle force à faire une croix sur une partie des fonctionnalités existantes depuis des années. Pour ne pas améliorer les choses, le draft du html5 est censé depuis mai 2011, ne plus subir d’évolution ce qui veut dire que les problèmes actuels ne vont pas s’arranger avec le temps.

Bah on fait quoi alors ?

On entends souvent dire ces derniers temps « Oui mais steve a dit que flash devait mourir« . Oui, mais si flash doit bien mourir un jour, ce n’est pas forcement pour le remplacer par le html5 comme on nous le présente jusque-là.

Les professionnels dont apple, ont vite compris que le html5 ne résoudrait rien et qu’il fallait voir plus loin. Et c’est pourquoi on à assister tour à tour, à la création de 3 nouveaux protocoles :

• HTTP Live Streaming développé par Apple
• Smooth streaming développé par Microsoft
• HTTP dynamic Streaming développé par Adobe

Pour faire simple, on a quasiment trois fois le même protocole. Ils n’ont pas les mêmes extensions, les mêmes manifest et les mêmes requêtes, mais ils fonctionnent tous sur le même principe.
Cela consiste à diffuser les vidéos via http comme dans le cas du pseudo streaming, mais pas sous la forme d’un fichier complet. Le téléchargement se fait sous forme de chunk (bloc de 10 à 30 secondes de vidéo).
On a donc un fichier manifest (un fichier texte sous forme d’un .xml, d’un .m3u8 ou autre) sur le serveur web qui est consulté régulièrement et qui indique au player quels sont les prochains morceaux de vidéos à télécharger.

Avantages de ces technologies :

• Elles sont basées sur HTTP, elles ne coutent donc pas cher à mettre en place et passent à travers les firewall et proxy
• Elles supportent très bien la monté en charge, car chaque nouveau chunk peut être distribué par des serveurs web différents
• Elles permettent l’utilisation de DRM au niveau du manifest car les chunk peuvent être cryptés
• Elles permettent le switch de qualité à la volée, car les chunk ont des keyframes alignés. En gros il est possible d’indiquer pour la même vidéo, plusieurs qualités dans le manifest. Le player peux alors adapter la qualité de la vidéo en fonction de la bande passante dont il dispose.
• Elles peuvent être utilisées pour du live avec un buffer d’une 30 ène de secondes (avec 1 ou 2 chunk d’avances)
• Codec unique, les 3 sociétés ayant une licence, elles ont toutes décidés d’utiliser le h264.

Désavantage :

• Hum ca prends un peu de temps à mettre en place, donc pour une utilisation personnelle il est conseillé de rester sur du pseudo streaming tant que Youtube ne s’y est pas encore mis.

Hors, le dynamic streaming d’adobe ne décolle pas, car remplacer flash par flash n’enthousiasme pas grand monde.
Le Smooth streaming commençait à voir son utilisation augmenter petit à petit, mais la subite mort de silverlight vient de le freiner brutalement (même s’il reste utiliser dans windows phone 7).

On est donc en train d’assister dans cette petite bataille à l’apparition d’un vainqueur : Apple
Il semblerait donc que la soi-disant unification du streaming vidéo provienne des appareils mobiles et pas des desktops comme le W3C le prévoyait.

Faites ce que je dis, pas ce que je fais!

Et c’est là qu’on commence à rigoler en comprenant l’ironie de la situation.
Apple est considéré par beaucoup comme l’un des principaux soutiens de cette balise vidéo, hors ils sont les premiers à déconseiller son utilisation, voir même à l’interdire.
Apple impose par exemple aux les développeurs d’application iOS d’utiliser exclusivement le HLS (HTTP Live Streaming) pour toutes vidéos durant plus de 10 minutes. Sans ça, les développeurs courent le risque de voir leurs applications refusées sur l’apple store. Traduction : « Elle est bien la balise vidéo, mais notre techno est quand même mieux ».

Encore mieux, Apple pour ne pas créer une nouvelle balise a modifié son implémentation de la balise vidéo HTML5 pour y accepter les URL de manifest HLS. Ils ont donc détourné le fonctionnement de la balise d’origine pour la rendre compatible avec leur protocole maison.

On a donc une situation où coté discours : « On fait du html5, regardez on utilise la balise vidéo » et coté pratique : « Oui mais avec un protocole vidéo pas prévu et indiqué dans aucun des draft du W3C »

Encore plus fort, mais passé relativement inaperçu en 2010 : Android supporte aussi ce protocole depuis honeycomb. Et avec la sortie de ICS, cette techno propriétaire sera prochainement supportée par plus de 90% du parc de smartphones et de tablettes. Et pour finir et assoir sa victoire dans le domaine, Apple a décider de soumettre le HLS à l’IETF il y a quelques mois pour en faire un standard.

Apple a donc choisi la voix inverse du W3C, faire d’abord quelque chose qui marche techniquement, et le soumettre après en tant que standard. Et ça a l’air de payer puisque HLS est parti pour couvrir dans les prochains mois une grosse part du marché des smartphones et des tablettes.

À quand les desktops ?

Conclusion :

Vous l’aurez compris, ma vision des choses n’est pas très encourageante pour la balise vidéo en tant que telle.
Autant d’un point de vue pseudo-streaming (fichier static), elle remplie à peut près son rôle, mais du coté streaming c’est loin d’être le même engouement.
Comme définie par le W3C, cette balise est trop limitée, trop contraignante et adaptée qu’à très peu d’usages. Difficile donc de l’imposer aux professionnels avec autant de lacunes.

Google et Apple semblent d’accord, l’avenir de la balise vidéo passe par le HLS. Microsoft va de son coté garder le Smooth streaming pour les windows phone et silverlight, mais ce choix différent n’est pas un problème. Il est assez facile de faire coexister HLS et Smooth streaming sur un même serveur, vu le peu de différences entre les deux protocoles.

Pour les desktops, la situation est nettement plus complexe. Safari supporte déjà le HLS via QuickTime, mais il est bien seul.
Pour tous les autres navigateurs, il faudrait donc utiliser la balise vidéo HTML5, avec les problèmes de performances, de fonctionnalités et de codec qu’elle amène.

Chrome va bientôt perdre le support du H264, Firefox et Opera sont toujours bloqués par ce même problème de codec vidéo. Il semble donc peu probable de voir le HLS adopté aussi vite que sur le marché des devices mobiles.
C’est la raison pour laquelle flash a encore de beaux jours devant lui sur nos machines de bureau. Tant que les différents navigateurs n’auront pas réussi à se mettre d’accord, ce qui peut encore être très long.

On peut dire après 2 ans de balise vidéo que le W3C a malheureusement partiellement raté le coche. Actuellement le choix le plus logique d’un point de vue professionnel reste de faire du HLS sur mobile et d’utiliser flash sur desktop, soit 2 technologies propriétaires.

Wait and see.