Sans vouloir trahir les secrets d’Apple et du kit de développement pour iPhone, voici quelques explications sur le streaming HTTP par Apple après un bref rappel historique.
Le concept du streaming classique
Apple tout comme Microsoft ont constaté les difficultés à faire fonctionner d’autre port que le port 80 (celui qui sert à envoyer les pages web jusqu’à votre navigateur). Les opérateurs mobiles ont des politiques draconiennes en matière de sécurité et autorisent uniquement le surf (donc le fameux port 80 et 443 pour les sites sécurisés en SSL). Certains opérateurs ouvrent généreusement les ports liés aux emails.
Ce qui est vrai sur mobile est aussi vrai à l’intérieur des entreprises. Pour contrôler au maximum la sécurité et les coûts de bande passante, les entreprises choisissent de limiter l’accès de leur salarié au web, la messagerie étant souvent accessible via un serveur sur le réseau local.
Dans ces situations le streaming peut importe son format : Flash, Windows Media, Real ou QuickTime, peut simplement ne pas fonctionner. C’est dommage car ces éditeurs utilisaient au mieux les fonctionnalités offertes avec notamment la notion de paquets échangés en mode non connecté (UDP) : si ça passe tant mieux, si ça passe pas tant pis, le logiciel devra se débrouiller. A noter que Flash est le seul format de streaming a utilisé exclusivement le mode connecté (TCP).
Les fragments de vidéos
Microsoft et Apple ont tenu compte de ces limitations. Alors même qu’il fallait anticiper le virage de la haute-définition et de la mobilité, ces deux sociétés ont pris le parti de faire du streaming sur le port 80 en échangeant non page des pages web mais petit morceau de vidéo. Ces fragments contiennent un très courte durée de données audio/vidéo : entre 2 et 10 secondes.
Partant de ce principe fondateur, les équipements filtrant des entreprises ont l’impression de voir des pages web ou des images. Certains équipements sont mêmes capables de conserver ces fragments une certaine durée pour les distribuer à d’autres personnes de la société qui consulterait le même contenu.
L’assemblage de fragments
Pour transformer ces fragments en vidéo, il faut un logiciel adapté. Les navigateurs Internet aujourd’hui ne savent pas lire réellement les vidéos ; ce n’est pas tout à fait vrai puisque les navigateurs implémentant HTML 5 tel que Firefox 3.5 ont maintenant quelques capacités dans ce domaine.
Apple fournit donc le logiciel adapté sur son iPhone OS 3.0 et le futur QuickTime X, Microsoft lui le fait avec son plugin Silverlight. Ces deux solutions font exactement la même chose : elle appelle un fichier descripteur (qui explique comment est fait la vidéo) et ensuite demande ses fragments, les assemblent et affiche le contenu audio/vidéo correspondant.
Dans le cas d’un streaming HTTP qui s’adapte en fonction de la bande passante (Edge/3G pour le mobile, bande passante fluctuante dans les autres réseaux non mobile) : quelques secondes de vidéos peuvent être interchangés avec l’équivalent de meilleure qualité ou dans une qualité dégradé, l’idée étant d’obtenir une expérience visuelle la plus fluide possible.
Et Adobe Flash ?
Flash a bâtit son succès avec les vidéos envoyées en HTTP, mais en mode téléchargement. Ce qu’on appelle progressive download. Cette méthode très basique exigeait de devoir charger la vidéo dans son entier pour se déplacer. Aujourd’hui des solutions existe pour ne retourner que la partie intéressante de la vidéo mais ce n’est pas aussi abouti que le streaming HTTP et surtout ça ne concerne pas les transmissions en direct.
Adobe n’a pas communiqué sur un quelconque streaming HTTP à ce jour : toutes les vidéos que vous consulter avec Flash fonctionnent sur un protocole bien particulier (RTMP).
Retard, stratégie, l’avenir nous dira quel éditeur a été le plus visionnaire… En attendant, les possesseurs d’iPhone vont rapidement pouvoir profiter de cette technologie au creux de leurs mains.
Mais le le protocole RTMP qui permet de faire du streaming , peut aussi être véhiculé ou tunnelé dans du HTTP.
En plus Adobe a aussi une fonction d’adaptation du stream qui est dynamic streaming
Je me trompe?
@champax, oui le protocole RTMP peut être tunneler dans des trames HTTP, il porte le doux acronyme de RTMPT. La différence avec le SmoothHD, c’est que seul Flash Media Server est capable d’interpréter ce protocole qui a l’avantage de passer les firewalls qui pourraient être récalcitrant aux ports de streaming classiques.
Concernant le streaming adpatatif, effectivement Adobe a sa propre version avec Dynamic Streaming qui continue de s’appuyer sur Flash Media Server – avec les avantages et les inconvénients que cela apporte (j’en parle un peu ici et là).