La diffusion de vidéo en ligne arrive à maturité

Arnaud de la Grandière |
Avec HTTP Live Streaming, la diffusion de vidéo en ligne passe un nouveau cap. Les contraintes techniques n'ont en effet pas manqué depuis les premières heures d'Internet pour diffuser de la vidéo dans de bonnes conditions. Streaming, progressive download, que se cache-t-il réellement derrière ces termes ?

Les pages web sont distribuées par le biais du protocole HTTP. Le navigateur demande au serveur la page HTML, un fichier texte qui contient notamment les adresses de chaque fichier utilisé pour sa mise en page, puis demande au serveur l'envoi de chacun de ces fichiers pour effectuer le rendu final. Les fichiers sont téléchargés, stockés dans un cache, et affichés. Il en va de même pour la vidéo, jusqu'il y a peu par le biais exclusif de plugins.

Ce procédé n'est pas sans inconvénients, puisque, en fonction du format de fichier (par exemple si la piste sonore est stockée après la piste vidéo au sein du fichier), il faut parfois attendre son téléchargement complet avant de pouvoir l'exploiter, ce qui peut s'avérer particulièrement gênant pour la vidéo, souvent synonyme de gros fichiers qui prennent donc du temps avant de pouvoir être consultés.

Fluctuat et mergitur

Afin de remédier à ce problème, on a mis au point différents protocoles, indépendants du HTTP, pour afficher les images le plus rapidement possible : le streaming était né. À Real Networks le RDT, à Microsoft le MMS, et à Adobe le RTMP. L'Internet Engineering Task Force (IETF, un organisme qui chapeaute les standards ouverts du web) a pour sa part mis en avant le RTSP, utilisé par Microsoft, Apple, et Real pour leurs serveurs de streaming. Bien que le RTSP soit libre de droits, ce protocole n'a guère été populaire en raison d'incompatibilités avec nombre de pare-feux.

Au sens le plus strict, le streaming diffère beaucoup de la conception qu'on en a communément aujourd'hui : les protocoles dédiés au streaming ouvrent une connexion de point à point entre le serveur et le poste client, et diffusent un flux de données que le poste client devra se charger d'afficher à mesure que les données lui parviennent. Ainsi, il devient possible de sauter d'un point à l'autre de la vidéo sans qu'elle ait à être chargée intégralement (une fonction que le HTTP ne prend pas en charge), ni d'attendre le chargement complet d'un fichier pour lancer sa lecture. De même, cette technologie rend possible la diffusion d'événements en direct sur le web.

Mais le streaming n'est pas sans inconvénients : en cas de congestion sur le réseau, on peut être amené à perdre des images, voire des pans entiers de séquence. Pire encore, si le débit de la vidéo, tel qu'il est envoyé par le serveur, est supérieur à celui de la connexion du poste client, la vidéo se transforme rapidement en diaporama. Pour y remédier, le streaming permet d'adapter le débit de la diffusion aux capacités constatées du poste client à mesure de leur évolution, une fonction cruciale à l'époque où le réseau téléphonique commuté était le principal mode de transmission.

D'autre part, qui dit protocole différent, dit logiciel serveur différent. Et puisque ces protocoles sont promus par des entreprises dépositaires des technologies concernées, le modèle économique (plugin/codec gratuit pour les utilisateurs finaux, logiciel serveur payant pour les diffuseurs) s'avère autrement plus onéreux : les logiciels serveurs se vendent à prix d'or.

Le HTTP n'a pas dit son dernier mot

Pour répondre à ces problèmes, les codecs vidéo ont pris en compte ces problématiques à mesure de leurs évolutions, et ont permis d'introduire le téléchargement progressif (progressive download), ou plus exactement la lecture des vidéos à mesure qu'elles sont téléchargées par le biais du protocole HTTP, introduite notamment dans QuickTime 3 en 1998. Ainsi, il n'est plus besoin d'attendre que le fichier soit intégralement téléchargé dans le cache pour que sa lecture commence. De cette manière, HTTP revêtait l'avantage de la diffusion instantanée comme pour le streaming, en plus d'être un protocole libre et gratuit, tout en conservant l'avantage de ne perdre aucun passage de la vidéo. En effet, les plugins se chargent de mesurer la quantité de cache nécessaire à stocker avant de commencer la lecture en fonction de votre bande passante afin que la lecture puisse se faire de façon ininterrompue, la fin du téléchargement devant idéalement arriver peu avant l'achèvement de la lecture.

Dans les faits, il n'est pas rare d'avoir à interrompre la lecture à cause des variations de débit qu'on finit immanquablement par rencontrer. C'est notamment cette technologie qui est à l'œuvre sur YouTube ou encore sur le portail des bandes annonces d'Apple.

Notons bien que les plugins des quatre acteurs principaux (Apple avec Quicktime, Adobe avec Flash, Microsoft avec Windows Media et Silverlight, et Real Networks avec Real Player) supportent aussi bien le streaming que le progressive download.

Malgré cette amélioration, le téléchargement progressif via HTTP conservait quelques inconvénients face au streaming : le lancement de la lecture ne se faisait pas aussi rapidement qu'en streaming, particulièrement sur les débits les plus faibles pour lesquels il faut stocker un cache plus conséquent. Le bitrate de la vidéo ne peut également pas être adapté au débit des postes clients, ce qui ne fait qu'alourdir les effets du premier point, et si on ne perd aucune partie de la vidéo, ce manque rend les interruptions de lecture en cours de chargement récurrentes. D'autre part, si l'utilisateur souhaite avancer la tête de lecture, il ne peut le faire que dans la limite de la partie déjà téléchargée de la vidéo, alors que le streaming permet de "sauter" directement aux dernières secondes de la vidéo à peine sa lecture commencée. Enfin, le progressive download ne permet pas la diffusion d'événements en direct.

Le meilleur des deux mondes

Pour remédier à ces inconvénients, Apple a mis au point un ingénieux système, baptisé HTTP Live Streaming, qui remédie à tous les manques de la diffusion par HTTP, et se paye même le luxe de quelques avantages sur le streaming. Sachant que le HTTP ne peut que diffuser des fichiers dans leur intégralité, du début à la fin, et non à partir de points arbitraires comme le permet le streaming, il suffit de "saucissonner" une vidéo en une kyrielle de fichiers de quelques secondes. Ainsi, pour peu que le logiciel client soit modifié en conséquence, il n'y a plus de problème pour sauter à un point arbitraire d'une vidéo à tout moment : le client se contente de demander au serveur la livraison du fichier correspondant. De même, il devient également possible, par le même truchement, de proposer un bitrate adaptatif : si le logiciel client note que le débit de la connexion est insuffisant pour suivre celui de la vidéo, il suffit de passer à une version alternative, d'un débit inférieur, au passage du morceau suivant, évitant ainsi l'effet d'embouteillage parfois rencontré avec le téléchargement progressif (dans la mesure des capacités du serveur). Cet élément a pour autre effet vertueux de rendre la nécessité d'un cache beaucoup moins prégnante, et de lancer immédiatement la lecture. C'est également ce qui a permis à l'Apple TV de se débarrasser de son disque dur. Enfin, la diffusion en « live » devient possible, comme on a pu le voir lors du dernier special event d'Apple. Comble du luxe, ce procédé apporte tous les avantages du streaming sans la moindre perte d'images.

trasnsport_stream


Concrètement, la vidéo est morcelée par le logiciel Segmenter, et les fichiers résultants sont référencés dans un fichier de liste de lecture dérivé du M3U, qui permet du côté client de connaître la durée totale de la vidéo, les versions alternatives par débit, et les morceaux à demander au serveur en cas d'avancement de la tête de lecture. En conséquence, HTTP Live Streaming nécessite quelques aménagements, tant du côté serveur que du côté client, pour fonctionner. Apple a introduit la gestion du HTTP Live Streaming dans iOS 3.0 et dans QuickTime X, livré avec Snow Leopard, et a proposé le standard à l'IETF. Microsoft avait également mis au point un procédé semblable, nommé Smooth Streaming, mais celui-ci a pour particularité de ne fonctionner qu'avec les solutions de Microsoft, tant du côté serveur que du côté client, alors que HTTP Live Streaming peut fonctionner avec n'importe quel fournisseur.

avatar yeyette | 
Sur le titre, moi j'aurais dit "Maturité"... pas vous ??? ;-))
avatar olanparis | 
Merci pour cet article fort intéressant !
avatar Yohmi | 
Merci pour cette vulgarisation de technologie complexe, ça fait toujours du bien d’avoir l’illusion de comprendre quelque chose à l’informatique. Moi, en tout cas, ça me donne un poil soyeux :D Par contre, lors de la diffusion Live, j’ai eu le droit à quelques couacs… certains segments n’avaient tout simplement pas d’image… enfin, peut-être est-ce en passe d’être corrigé. Ou c’est ma connexion (qui n’est pas directe, et qui parfois bloque sur un élément sans raison). D’autres ont-ils constaté le même genre de comportement ?
avatar pseudo714 | 
Article très intéressant. Merci.
avatar Funji | 
En tout cas moi sur mon iPhone c'était haché, et j'ai du quitter plusieurs fois pour retrouver une vidéo normale.
avatar Dagui | 
Ben moi j'ai clairement vu les changement de débit, comme si la vidéo passait en basse def'. Et j'ai eu quelques saccades/coupures, très stressant d'ailleurs, en pleine présentation de l'TV. [edit: tiens, ma pomme s'est faite croquée..., re-edit: ben elle est revenue...]
avatar Arnaud de la Grandière | 
Les serveurs d'Apple ont eu un peu de mal à tenir la charge à certains moments, mais ça ne remet nullement en question la validité de HTTP Live Streaming.
avatar maestric | 
Bon article, merci.
avatar Sylvain_ | 
Les problèmes d'écrans noirs pendant la diffusion ressemblaient plus à des "dropped frames" de l'encodeur qu'à la diffusion elle-même (surtout que le son continuait, alors que son et video sont collés ensemble dans le HTTP Streaming), certains encodeurs ne garantissant pas la non-perte de frame. Le protocole n'empêche pas les interruptions, mais ça les diminue grandement. J'ai personnellement regardé le flux le plus haut débit de la conf de bout en bout depuis une connexion fibre chez NC, avec aucune coupure autre que ces "dropped frames" Sinon HTTP Streaming est largement moins gourmand que Silverlight surtout en ressources. Sur un PC dernier cri, difficile de faire autre chose que regarder un flux Silverlight alors que sur mon Macbook Core Duo de 4 ans, je peux sans problème regarder 3 flux HTTP Streaming en simultané et toujours avoir de l'activité derrière.
avatar mefysto | 
Quel est l'avantage du streaming alors ?( ou carrément du HTTP Live Streaming ) si il faut : Modifier les serveurs Créer beaucoup de petits fichiers Faire plusieurs versions en fonction du débit ( 240p , 360 ,720 , 1080p ) Alors que le progressive download requiert aucune modification et simplement une petite attente pour charger la vidéo quel débit faut-il pour du 240p ou du 360p ou du 720p et enfin du 1080p pour être visionné sans aucune coupure ? ( En progressive download sans attendre que la vidéo charge et en Streaming )
avatar Arnaud de la Grandière | 
@ Mefysto : les avantages de HTTP Live Streaming sur le progressive download sont de permettre la diffusion en direct (comme le special event), de pouvoir passer à n'importe quel point de la vidéo sans préchargement, d'adapter le bitrate de la vidéo au débit de la connexion, et de ne pas nécessiter de gros cache (toutes choses impossibles en progressive download). La création des petits fichiers se fait de manière automatique. Les avantages de HTTP Live Streaming sur les différents protocoles de streaming sont qu'il ne coûte rien pour les diffuseurs, qu'il permet d'utiliser tout format de video, et qu'à la réception on ne perd jamais de passages de la vidéo en cas de congestion du réseau. Le système de playlist est également très souple puisqu'il permet d'intégrer d'autre séquences et de faire des montages dynamiques (coupure pub, etc). le 720p ou le 1080p sont des résolutions et non des débits. On peut compresser les vidéos à ces résolutions vers à peu près n'importe quel débit, mais pour une image de bonne qualité en 1080p à 30 images par seconde il faut compter environ 6 megabits par seconde.
avatar mefysto | 
@Nonoche : Merci de ta réponse rapide. Je comprends mieux l'interet du HTTP Live Streaming maintenant. J'ai néanmoins une dernière question : sûr une vidéo qui n'est pas en direct ( genre une vidéo youtube ) on peux donc passer sans chargement à n'importe quel point de la vidéo ? et le serveur adapte automatiquement la qualité. Si c'est ça c'est absolument énorme, pourquoi personne ne l'utilise ? A oui , quel est l'interet de compresser une vidéo de résolution 1080p pour un débit requis moins important si la qualité d'image est équivalente a du 720p voir moins ?
avatar diboutra | 
et concrètement, avec ce procédé, est ce qu'une connexion à 1 mega suffira pour profiter pleinement des services de l'apple tv ? En terme de qualité image ?
avatar Arnaud de la Grandière | 
@ mefysto : oui, avec HTTP Streaming on peut passer à n'importe quel moment de la vidéo sans attendre le chargement, et la qualité de la compression s'adapte au débit de ta connexion (tout ça est dans l'article ;¬). La technologie a été proposée à l'IETF l'année dernière, mais la standardisation est un processus long. Malgré tout des sociétés comme Akamai (diffuseur) ou Roku (concurrent de l'Apple TV) exploitent d'ores et déjà HTTP Live Streaming. Pour ce qui est de compresser du 1080p, encore une fois il s'agit d'une résolution (1920×1080). La qualité de l'image dépend de nombreux paramètres : caractéristiques de l'image (vidéo ou dessin animé par exemple), mouvements brusques et/ou vastes dans la séquence (les reflets du soleil sur l'océan en plein cadre, ça ne pardonne pas ;¬), plans courts, qualité du logiciel de compression, et bien sûr le débit paramétré à la compression (certaines vidéos, tournées spécialement pour le web, tiennent compte de ces diverses contraintes dans leurs mises en scène). Même si la compression et la résolution sont deux éléments distincts, en deçà d'un certain seuil ça n'a effectivement que peu d'intérêt de préférer le 1080p au 720p. Sachant qu'une minorité de connexions sont capables d'atteindre les 6 Mbps pour recevoir le 1080p dans de bonnes conditions, on préférera le progressive download pour cette résolution, quitte à devoir patienter au chargement (raison pour laquelle l'Apple TV s'arrête à 720p, [url="https://www.igen.fr/apple-tv/apple-tv-pour-quelques-pixels-de-plus-14921"]voir ici[/url])
avatar Sylvain_ | 
Y'a déjà un paquet de gens qui l'utilisent mais on ne le sait pas. En France, le plus gros actuellement, c'est Canal+/CanalSat, sur iPhone, comme sur Android. SFR, Bouygues diffusent aussi comme ça leur TV sur iPhone.
avatar Arnaud de la Grandière | 
@ diboutra : pour les vidéos en 720p, 1 Mbps ça fait très juste. Pour une bonne qualité d'image il faut compter entre 2 et 3 Mbps. Bien sûr le SD passe sans problème (et tu peux toujours diffuser des vidéos stockées sur ton ordinateur vers l'Apple TV avec AirPlay).
avatar melaure | 
@ derniers posteurs, effectivement le débit est très important. Je vois arriver gros comme une maison ceux qui vont dire, ça y est le support est mort. Hé bien non désolé, si c'est pour avoir du compressé médiocre, sans moi. Un bon BR c'est du 20/25 Mbit/s (et même plus de 40 Mbit/s pour les meilleurs), alors si plusieurs millions de personnes regardaient ce genre de flux, le net explose ;) Le net peut peut-être suffire pour des petits bitrates, mais ça n'a rien à voir avec ce que veulent les gens qui aiment le cinéma et les belles images ! C'est d'ailleurs assez amusant de voir Jobs pousser à tout prix la vidéo en ligne, alors que les US sont carrément à la ramasse par rapport à nous en ADSL. A part les américains des villes, les autres vont pas voir grand chose ... ;) Par contre bonne chose d'utiliser le http et pas un truc propriétaire. Si seulement iChat était du même acabit, on n'aurait pas autant de problème de communication ...
avatar Anonyme (non vérifié) | 
@Sylvain_ Sauf erreur de ma part, l'HTTP Live Streaming n'est pas géré en natif sur Android. Sais-tu ce qu'utilise Canal sur Android pour gérer le HTTP Live Streaming ?
avatar rva1mac | 
C'est vrai que iChat mériterait bien du HTTP Live Streaming.
avatar momo-fr | 
Pour ma part, avec une connexion autour de 6 mega j'ai vu le keynote démarrer avec plein de saccades et décalages, sans rien toucher cela c'est progressivement calé (une à deux minutes environ pour y arriver), par la suite plus de problème, c'était fluide mais quelques pâtés de pixels ont apparus de temps à autre. Pour une première j'ai trouvé ça pas mal...
avatar Almux | 
Il est bien clair qu'Apple ne se lancerait pas dans une nouvelle stratégie, si l'infrastructure ne donnait pas des signes très net de maturité!
avatar Sylvain_ | 
@broc79 Il y a déjà eu plusieurs players HTTP Streaming sur Android, les derniers asiatiques ont un player intégré qui le supporte, des STB aussi (y compris chez les Français). Canal+ a fait développer par une boite française.
avatar Cybry | 
Au delà des encapsulations et des codecs, la solution pour ne pas engorger les coeurs de réseau avec des flux video de plus en plus gros passe par le multicast (n'envoyer qu'une seule instance d'un flux vers le réseau depuis la source, et le réseau gère seul l'arbre optimal de diffusion entre la source et les abonnés au flux). Les protocoles qui vont bien sont mis en oeuvre sur les réseaux des différents FAI pour leurs besoins propres (diffusion TV...), mais pas ENTRE eux. Il me semble aussi que des sociétés genre Akamaï réfléchissent à (ou sont capables d'offrir aujourd'hui ?) une infra de transport multicast au dessus de tout internet , via des tunnels entre leurs passerelles, mais ça reste un support non optimal du modèle. Je ne crois pas
avatar thierry61 | 
Akamaï intervient sur les problématiques de diffusion streaming. On peut d'ailleurs penser que, malgré la sophistication croissante des protocoles de diffusion, le rôle des acteurs CDN devrait continuer de s'accroitre compte tenu de l'irruption de la HD (cf la discussion 720p vs 1080p)
avatar Psylo | 
Vieux Troll : Utiliser le protocole http pour streamer de la video en passant par le port 80.... quelquepart c'est un peu une hérésie. Le web est en train de tuer internet.

Pages

CONNEXION UTILISATEUR